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

[Prasanna S Panchamukhi <prasanna at in dot ibm dot com>]

Hi,

>That brings me to the other question -- typically whenever we have
>a call-chain of this sort, policy isn't very far behind ... quite
>soon we find ourselves wanting priorities between handlers or
>to decide whether to continue calling rest of the handlers or
>short circuit through depending on the result of an earlier handler
>etc. Sort of like notifiers ...

>But in the more general case, is the design flexible enough to
>allow policy to be built _over_ this infrastructure (again of course
>without cluttering the core kprobes logic) ?

My earlier implementation of adding different object like

+struct multiprobe {
+       struct hlist_node hlist;
+       struct kprobe kp; /*individual kprobes structure*/
+};

is to provide flexiability to add priorities between handlers. We can
also add some flags to short circuit through depending on the result of
the earlier handlers. Also we can add new interfaces to changes these flags
and disable particular handler.
Even this flag can be used to provide exclusive access to only one particular 
handler in the handlers list.

Please see this patch for more details.
http://sourceware.org/ml/systemtap/2005-q2/msg00074.html

Adding different interface and different objects for multiprobe feature
is to provide a flexiability to add new features such as priorities without
even changing the existing/core kprobes.

Thanks
Prasanna
-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>