[RFC] Multiple kprobes at an address redux (take3)
Maneesh Soni
maneesh@in.ibm.com
Wed Apr 13 04:47:00 GMT 2005
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
More information about the Systemtap
mailing list