[lkml]   [2003]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 /
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.351 / U:6.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site