Messages in this thread |  | | Date | Tue, 18 Feb 2003 11:12:15 -0300 | From | Werner Almesberger <> | Subject | Re: [RFC] Is an alternative module interface needed/possible? |
| |
(I think we should limit the Cc:s to Roman, Rusty, the list, and me, and leave the others in peace. Please yell if you really want that extra copy :-)
Roman Zippel wrote: > Basically I can agree with this, although I'd like to avoid that we > iterate too much over these steps, as it would too easily divert the > discussion to other things, so I'd rather take smaller steps and keep the > scope a bit broader.
Good :-) I want to avoid modules as much as possible, because they've extensively been tackled in the past (which didn't help much making the interfaces better), and also because they're just a bit too political an issue.
Okay, this brings us to the issue of broken interfaces. Do we have agreement that there are cases where interfaces like remove_proc_entry, in their current state, cannot be used correctly ?
Example:
static ...callback...(... struct file *file ...) { void *user = PDE(file->f_dentry->d_inode)->data;
... do something with "*user" ... }
... struct proc_dir_entry *de = create_proc_entry(...); void *my_data;
de->data = my_data = kmalloc(...); ... remove_proc_entry(...); /* what happens with "my_data", formerly known as "de->data" ? */
a) kfree it. May cause an oops or other problems if we're in the middle of the callback.
b) don't kfree it. So we now have a (hopefully small) memory leak. Problem: my_data may point to a lot more than just some tiny allocation.
Okay so far ?
(Possible solutions on the next, slid^H^H^H^Hposting :-)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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/
|  |