Re: [RFC] Multiple kprobes at an address redux (take3)

[Maneesh Soni <maneesh at in dot ibm dot com>]

On Tue, Apr 12, 2005 at 03:15:51PM -0400, Ananth N Mavinakayanahalli wrote:
> Suparna Bhattacharya wrote:
> 
> Hello Suparna,
> 
> >It would be nice to summarize all the requirements upfront, before
> >moving on to the design.
> >
> >One observation I have is that a register_single_kprobe equivalent 
> >is still useful for those who might be setting up a kprobe for debugging
> >or fault injection purposes --  or rather maybe something like
> >register_exclusive_kprobe, because one might not want to be surprised by
> >having multiple handlers clicking away in such a situation.
> 
> Yes, this is something we have to be congnizant of. So, here is what I
> propose:
> 
> We have a "coexist" field in struct kprobe which is default 0. This
> means that the kprobe cannot tolerate other kprobes at the same address.
> A non zero value would indicate the kprobe can be one of many at the
> address.
> 

Ananth,

At this time I think "coexist" will be an overkill as we now know that 
theoriticaly there can be same problems even with kporbes on adjacent 
instruction as with coexisting kprobes.

[..]
> >
> >Nomenclature wise - both aggr_probe and multi-probe are names that
> >sound more like a set of different probes, not multiple handlers
> >for the same probe as is really intended. Ideas for better names ?
> 
> "manager kprobe"? Don't know what would be a good name, really :)
> 
IMO, register_kprobe_single() for low-level uses and register_kprobe() for
normal uses are ok.


Thanks
Maneesh


-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990