Re: [PATCH 0/3] tracepoints: delay argument evaluation

[Jason Baron <jbaron@redhat.com>]

On Tue, May 19, 2009 at 05:17:04PM -0400, Mathieu Desnoyers wrote:
> * Jason Baron (jbaron@redhat.com) wrote:
> > hi,
> > 
> > After disassembling some of the tracepoints, I've noticed that arguments that
> > are passed as macros or that perform  dereferences, evaluate prior to the
> > tracepoint on/off check. This means that we are needlessly impacting the 
> > off case.
> > 
> > I am proposing to fix this by adding a macro that first checks for on/off and
> > then calls 'trace_##name', preserving type checking. Thus, callsites have to 
> > move from:
> > 
> > trace_block_bio_complete(md->queue, bio);
> > 
> > to:
> > 
> > tracepoint_call(block_bio_complete,  md->queue, bio);
> > 
> 
> I knew this limitation in the first place, but decided it was not worth
> uglifying the tracepoint call site for it.

hmmm...i don't think its terribly ugly.

> 
> The expected use is to pass a pointer or a value as tracepoint argument
> and dereference it in the callback attached to it.
> 

there are a lot of tracepoints that pass more than just a pointer...do
we want to be slowing up i/o paths, when tracepoints are disabled?


> Is there any _real_ added value for going through this API change pain ?
>

the value is in being able to define the tracepoint api more easily to
one's liking and not have additional instructions in the off case, where
they can easily be avoided.

thanks,

-Jason