> 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?
I removed the stuff I said about locking issues. They probably exist, but I
am not quite sure how they would be solved. So I instead focused on the
efficency aspects.
The reason they are less efficient is because, as long as there is one
subscriber to the notifer list somewhere on the system, you always have
a list to walk. With process notification, you only walk the list if
a kernel module is interested in a given task. That way, if a kernel
module is only associated with a few tasks on the system, we don't end
up walking lists all the time.
The other piece that is missing is a data pointer associated with a task.
Without that, you'd have to add entries to the task struct or implement
table lookups to find data associated with processes.
One solution that Jack Steiner actually wrote up a prototype for over
the weekend is notifier lists in the task struct itself. So if that
is interesting to folks, we have at least some data on it. I haven't
tried to implement Job on top of it yet but if people think that
direction is interesting, I can implement Job on this sooner. Otherwise,
I'm more comfortable with something closer to PAGG that has received a lot
of exposure already and has all the features the community here has
requested so far (except for one outstanding request from Kingsley).
Erik
|