Erik wrote:
> I'm looking for feedback on these ideas.
Oohhh - lots of nice words.
A couple of random thoughts on first glance now, then I will try to
give this a closer read later today.
Let me place in evidence the other notifier thingies currently in the
kernel:
dnotify - directory (Stephen Rothwell)
fsnotify - filesystem (Robert Love - a 'FAM' like thing)
inotify - inode based (John McCutchan - basis of fsnotify)
notify - generic (Alan Cox needed for network devices)
First, observe that these other notifiers don't use two-letter
acronyms, but rather pseudo-words, to name themselves and to prefix
their kernel global symbols.
The "TN" name is too cryptic.
You need a pseudo-word, that you use consistently and methodically,
every place possible. When someone sees a line of kernel code
mentioning "inotify_inode_queue_event", they have a pretty good idea
what sort of subsystem is involved. When someone sees a mention of
"pn_get_subscriber", they will likely not realize this as quickly.
Perhaps a few long standing types in the kernel, such as tasks and
inodes, get to use the very short, familiar names of just a letter or
two, but the less well known types requirer longer more explicit names.
Besides the base name 'notify', two other possibilities that come
to my mind for the base part of the name are 'callout' and 'hook'.
I'm partial to 'callout'. For one thing, this distinguishes rather
nicely between two different mechanisms:
1) Some thread is asking to have notice sent to it of particular
kinds of events, and
2) You want threads to callout to an extra piece of code when they
undergo particular kinds of events.
The rule of thumb I'd suggest is to use 'notify' when the receiver is
some other thread, and 'callout' when the receiver is a code snippet
executing in the context of the thread originally experiencing the
event of interest. Beware that the above "notify" mechanisms may or
may not follow this rule of thumb; I don't know without thinking
harder than I want to right now.
There are 268 instances of the 7-char string "callout" in all
the kernel source, 5273 instances of the 5-char string "notif",
and 2456 instances of the 4-char string "hook".
In the 28534 symbols that list in a "nm vmlinux" of a kernel
I have at hand, there are 10 instances of the 4-char string "hook",
161 instances of the 5-char string "notif", and zero (0) of "callout".
So besides having a suitable meaning, "callout" doesn't collide
with existing kernel names.
Other words that come to mind that might be worth playing with
here: trigger, event, handler and exit (as in IBM's MVS "user
exit", "file exit" and "installation exit".)
You might want to peruse the literature for IBM-style exits, and look
for an opportunity to get someone from IBM with experience in such
mechanisms to contemplate what it would take to provide them for Linux
in a community acceptable form. However, "callout" will convey the
intended meaning to far more Linux hackers than "exit", which will
only convey the intended sense to those with IBM background (or at
least a beer drinking friend who is expert in such ;). If this were
MVS, I'd be recommending "task exit".
In any event, you might want to list the other notifier like mechanisms
(listed above) in your post, and compare and contrast (whatever
happened to Carl Rigg ?) them with your proposed mechanism.
Anyhow ... a couple more thoughts, besides the naming issue.
If the current notifier lists have technical limitations with locking
and efficiency, then what would it take to fix them up, rather than
introduce a new mechanism? Are these limitations inherent and
unavoidable in any mechanism that has the API of the current notifier
lists, or are they an internal accident of the implementation? If the
latter, can the implementation be fixed? If the former, can you
clearly explain why notifier list, or anything so conceived and so
dedicated with such an API, must necessarily suffer from such technical
limitations?
A key concern, which you face head on (good!) is that such mechanisms
as this "allow interesting things to be implemented outside of the
kernel." You explain nicely why we need such, but you don't explain
how we keep some proprietary competitor of Linux from abusing your
mechanism. I'd prefer that this mechanism only allow GPL loadable
modules to hook into it, and I wish there were someway to ensure
that the portion "outside the kernel" was also GPL. There are legal
and competitive business issues here that need to be addressed.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxx> 1.925.600.0401
|