Re: [Fwd: [Announce] Non Invasive Kernel Monitor for threads/processes]

[Peter Williams <pwil3058@xxxxxxxxxxxxxx>]

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
> and exit.

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
> PAGG.

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
> hooks,

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
Peter
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