Messages in this thread |  | | | Date | Mon, 24 Feb 2003 13:14:27 +0100 (CET) | | From | Roman Zippel <> | | Subject | Re: [RFC] Is an alternative module interface needed/possible? |
| |
Hi,
On Sun, 23 Feb 2003, Kevin O'Connor wrote:
> 8) Have the unregister code (remove_proc_entry) set an external flag (eg, > de->data_is_there), and update all users of de->data to check the flag > before following the pointer. > > Option 8 may not qualify as "sane", but I think it is important to add it > because it is what the module code is currently using. Thus, one need not > look at the module stuff as a "special case", but as a general (if > complicated) resource management solution.
Yes, it's another possible solution, but it has the same problem as the current module locking - increased locking complexity. Such flag actually exists already ("deleted"), but no user can use it currently, because the read/write functions don't have the proc entry argument. Even if they could use it, switching this flag isn't enough remove_proc_entry also had to synchronize with active users, so users had to take some lock just to read the data, where a simple reference was sufficient before.
bye, Roman
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |