> * Mathieu Desnoyers (
mathieu.desnoyers@polymtl.ca) wrote:
> > * Mike Mason (
mmlnx@us.ibm.com) wrote:
> > > Hi Mathieu,
> > >
> > > 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.
> > >
> >
> > Nope, but I know we will have to address this.
> >
> > Something along the lines of walking an RCU list of function pointers,
> > calling them.
> >
> > 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 ?
> >
> > Mathieu
> >
>
> I'm working on an implementation.
>
