This is the mail archive of the
mailing list for the systemtap project.
Re: [to-be-posted-soon] Multiple handlers per marker
- From: Mike Mason <mmlnx at us dot ibm dot com>
- To: Mathieu Desnoyers <compudj at krystal dot dyndns dot org>
- Cc: ltt-dev at shafik dot org, linux-kernel at vger dot kernel dot org, systemtap at sources dot redhat dot com
- Date: Mon, 05 Nov 2007 14:46:59 -0800
- Subject: Re: [to-be-posted-soon] Multiple handlers per marker
- References: <472A345C.firstname.lastname@example.org> <20071101221530.GC19700@Krystal> <20071102033654.GA1301@Krystal> <20071104232442.GA32320@Krystal>
Mathieu Desnoyers wrote:
* Mathieu Desnoyers (email@example.com) wrote:
* Mathieu Desnoyers (firstname.lastname@example.org) wrote:
* Mike Mason (email@example.com) wrote:
I'm working on an implementation.
Hi Mathieu,Nope, but I know we will have to address this.
Are you aware of any working being done to allow multiple handlers to be
attached to a marker? Something like what kprobes allows. I've started to
look into this and don't want to duplicate efforts.
Something along the lines of walking an RCU list of function pointers,
The only downside I see is that we will have to pass a va_list * instead
of real va args. The could make the marker site a little bit bigger and
will change the probe callback arguments.
What do you think about these ideas ?
If we can find a way to make the common case (only one probe connected)
_ultra_ fast, and yet architecture independent, that would be awesome. A
simple call is kind of hard to beat though.. So we may have to think
about a design with :
- One call at the marker site
- if 1 probe is installed :
- If the format string is empty, connect a probe without va args.
- If the format string is not empty, connect a "stage 1" probe that takes
the va args, starts/ends the va_list and calls _one_ function (let's
call it "stage 2" probe), that takes va_list as parameter.
- if more than 1 probe is installed :
- The stage 1 probe creates the va_list and passes it to each function
connected, iterated with an RCU list.
What do you think ?
It's ready for testing. Please grab
patch name :
This patch alone doesn't apply cleanly at all on 2.6.24-rc1-git14. Are there other patches in this series I should apply first?
It still need to go through patchcheck.pl and some polishing, but it
seems to work fine for me with multiple probes (the sample marker,
sample probe and multiple instances of my lttng probes can
connect/disconnect without problem).
Currently, the "connect/disconnect" and "arm/disarm" operations are
separate. However, they could be merged. Any comment/preference on this?
Being separate, a probe provider can wait until the very last moment
before it activates its markers, with a minimalistic impact on the
system, but it is not such a strong argument.