[lkml]   [2003]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Is an alternative module interface needed/possible?

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.125 / U:1.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site