Roman Zippel wrote:
> Anyway, for now just keep this option in mind and let's look at the other
> options, which don't require a module API change.
Yes, we can look at the modules case at the end.
> In that case it would be kernel memory, which cannot be freed, so it will
> not go away and requires no module count.
kfree isn't the only way to make data unusable. Remember the
"my_state" example.
> > Likewise, possibly dynamically allocated data that is synchronized
> > by the caller, e.g. "user" in "struct proc_dir_entry".
>
> user?
"data", sorry. I always call this kind of argument something like
"user" in my code ...
> A generic file system as it's registered via register_filesystem.
Okay, I'll have a look at that.
> Um, it's getting late and I just played too much with procfs to find a
> sensible solution. Below is an experimental patch to add callback which
> would allow it to safely remove user data. Very lightly tested, so no
> guarantees.
Yep, that's the kind of callback I had in mind.
- 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/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:24 EST