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/