Paul Jackson wrote:
This seems to be doing what PAGG does (or should do).
I'm not a PAGG expert, so my questions here are not definitive of what
PAGG does or should do.
However, I will confess to some puzzlement over your suggestion that
such is the same as it is for the kernel monitor described in your note.
I guess that I really meant an overlap in functionality rather than an
exact match :-)
I certainly see _some_ commonality in mechanisms, with one or another
flavor of flexible and dynamically modified hooks in places such as fork
This is what I meant to draw to your attention.
But other mechanisms, such as filtering and queueing of events for
transmission to a user deamon, don't match anything I was aware of in
To my mind this part is just something that could be implemented with
PAGG if you wanted to.
And other mechanisms that I thought existed in PAGG, such as a sort of
named callout to code in loadable kernel modules to be executed at such
I don't think that PAGG has this but I'm sure that a PAGG client module
could do that.
and such as some way of grouping related tasks which are to
receive common treatment, I didn't notice, in my cursory reading, of
this monitor mechanism.
No. But what it does have is callbacks in the same place in the kernel
that PAGG wants to put callbacks. I can't see multiple callback hooks
in the same place getting accepted into the vanilla kernel so if this
one was accepted it would make it hard for PAGG to get accepted. My
e-mail was meant as a "heads up" on this possibility.
And I am at a loss to guess what you know that PAGG "should" do distinct
from what it does.
I'm referring to the extensions to PAGG that I've posted on this list.
They add callbacks for changes to ruid, rgid and CPU affinity (mask) to
the callback in exec().
Perhaps it would help if you stated explicitly what you understand PAGG
does, and should do, rather than leaving that as unspoken implication.
See previous paragraph. I wasn't being critical and I'm sorry if you
interpreted it that way.
I like PAGG very much and in addition to the patches mentioned above I
have sent patches that implement the "task initialization" mechanism
during registration of a client and also code that automatically cleans
up during deregistration which makes writing clients much simpler and
greatly decreases the chances of leaving the kernel in an unstable
state. As I understand it, Erik has been too busy with other matters to
incorporate these changes into the official version of PAGG yet but he
promises that he will get around to it soon.
Sorry if I offended you
PS I was hoping that, as a result of my e-mail, somebody from PAGG would
contact this guy and try to talk him into doing his stuff using the PAGG
interface rather than inventing another one.
Peter Williams pwil3058@xxxxxxxxxxxxxx
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce