> > > int register_returnprobe(struct rprobe *rp) {
> > ...
> >
> > > independent of kprobe and jprobe.
> > ...
> > >
> > > make unregister exitprobes independent of kprobe/jprobe.
> > >
> > ...
> >
> > 1. When you call register_j/kprobe(), if kprobe->rp is non-null, it is
> > assumed to point to a retprobe that will be registered and unregistered
> > along with the kprobe. (But this may make trouble for existing kprobes
> > applications that didn't need to initialize the (nonexistent) rp
> > pointer. Probably not a huge deal.)
>
> I suppose if pairing of entry and return probes is important for a user,
> he/she can always do the following:
>
> static int ready; // 1 = everybody registered
> // 2 = everybody knows we're registered
> ...
> ready = 0;
> ... register_kprobe(&kp)...
> ... register_retprobe(&rp) ...
> /* instant XXX -- see below*/
> ready = 1;
>
> and in kp.pre_handler do
> if (!ready) {
> // return probe not registered yet
> return 0;
> }
> ready = 2;
> <body of handler>
>
> and in rp.handler do
> if (ready != 2) {
> // Probed function entered during instant XXX,
> // so kp.pre_handler didn't act on it.
> return 0;
> }
> <body of handler>
>
> Keeping a whole group of kprobes, jprobes, and retprobes in the starting
> gate pending a "ready" signal (e.g., for SystemTap) could probably be
> handled similarly.
>
> Unregistration shouldn't be an issue. At any time you can have N active
> instances of the probed function, and have therefore recorded E entries
> and E-N returns. Hien's code handles all that on retprobe
> deregistration, but the user's instrumentation should never count on #
> probed entries == # probed returns.
>
Jim,
You can do something like you explained above to handle the pairing issues.
You need to provide simple and compact interfaces for return probe feature.
Thanks
Prasanna
--
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
