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

Peter Williams wrote:
> 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.

I just noticed on LKML that someone else has suggested that these guys 
look at PAGG (and some other options) :-)

-- 
Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce