Messages in this thread | | | Date | Tue, 18 Feb 2003 14:22:57 -0300 | From | Werner Almesberger <> | Subject | Re: [RFC] Is an alternative module interface needed/possible? |
| |
Next round: possible remedies and their side-effects. As usual, if you disagree with something, please holler.
If yes, let's look at possible (and not overly insane) solutions, using remove_proc_entry as a case study:
1) still don't kfree, and leave it to the user to somehow minimize the damage. (Good luck :-)
2) add a callback that is invoked when the proc entry gets deleted. (This callback may be called before remove_proc_entry completes.) Problem: unload/return race for modules.
3) change remove_proc_entry or add remove_proc_entry_wait that works like remove_proc_entry, but blocks until the entry is deleted. Problem: may sleep "forever".
4) make remove_proc_entry return an indication of whether the entry was successfully removed or not. Problem: if it wasn't, what can we do then ?
5) like above, but don't remove the entry if we can't do it immediately. Problem: there's no notification for when we should try again, so we'd have to poll.
6) export the lookup mechanism, and let the caller poll for removal. Problem: races with creation of a new entry with the same name.
7) transfer ownership of de->data to procfs, and set some (possibly configurable) destruction policy (e.g. always kfree, or such). Similar to 2), but less flexible.
Any more ?
I think that most programmers would intuitively expect an interface of type 3). In cases where we can't sleep, either type 2) or type 5) would be common choices.
Does that sound reasonable so far ?
I'll wait a little until I continue with ways for dealing with the side-effects.
- 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/
| |