This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Design + prototype: Multiple handler sets per probe address


Hi Ananth,

Your design looks good to me, but I have some comments.

>1		 Multiple handler sets per kprobe
>
>1.1		 Overview
>
>One of the requirements of SystemTAP is the capability of defining 
>multiple handler sets per probe address. Current design of kprobes 
>does not allow the registration of more than one set of handlers 
>(pre, post, fault, break) per address.
>
>This is an attempt to come up with a design that will enable a user
>to define multiple handler sets per probe address. 
>

Another alternative approach to your design would be to define multiple 
handler sets per probe manager external to kprobes as a kernel module. 
..well the external module so called "systemtap" will register only one
probe at a given address. Once the probe is fired, kprobes gives control to
 handler registered at that address, now this handler check if there are
multiple handler registed and call then in sequence. This feature can be kept
within the systemtap module. Even for jprobes this logic will work.

Suparna pls pitch in and correct me.
The main goal of this approach is to define several objects/interface without 
changing the existing kprobe's code. 
You can define several objects based on struct kprobe object which is per probe/
per address/entrypoint.

struct agg_struct { /* per probe object but with multiple handlers defined*/
		list of handlers per probe;
		union probe { 
			struct kprobe *kp;
			struct jprobe *jp;
		}
	};
You can #define MAX_HANDER_PER_PROBE to some value (arrived based on 
requirement/practial results).

Also you can define a manager object.

struct Mgr_probe { /* list of probes with multiple handlers */
		list of struct agg_struct ;
		semaphore probe_sem;
		/*some locking mechanism to handle this Mgr_probe data structure*/
		unsigned long flags ; /*to manage the list */
		};

You can #define MAX_SYSTEM_PROBES to some value based on usage.
Useful to list all the probes with multiple handlers etc.

Some intefaces to insert and remove probes.

insert_kprobe(struct kprobe *kp) {
/ insert_jprobe (struct jprobe *jp) {

	........................
}

This routine should take care of two things
1. First time invocation of insert_k/jprobe() at a given address.
2. Subsequent invocations of insert_k/jprobe() at the same address. 

where in for the first time invocation of insert_k/jprobe() at a given address,
you actually invoke register_kprobe() and in subsequent insert_k/jprobe() call 
will just add the handlers to the agg_structure.


remove_kprobe(struct kprobe *kp) {
/remove_jprobe (struct jprob *jp) {

	........................
}

You need to take care of removal of probe handler if not the last one on the 
list and calling of unregister_k/jprobe() if it is last on the list.

Note : A word of caution

	Special care should be taken in handling of multiple handler invocation
at a given address such that you return proper values such as invocation of 
jprobe_return() once all handlers are in the list are invoked.

Let me know if you need more information.

Thanks
Prasanna
-- 

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]