* David Bryant (david.bry...@quantum.com) wrote:
> Hi all,
>
> Is it feasible to have an officially supported way of determining if a  
> tracepoint is currently enabled?
>
> In my code I would like to test if the tracepoint is enabled, and if it  
> isn't, avoid doing expensive setup work.
>
> I've been doing the following:
>
>   if  
> (__builtin_expect(!!(__tracepoint_sample_component___message.state), 0)) 
> {
>       /* setup work */
>       tracepoint(sample_component, message);
>       /* cleanup work */
>   }
>
> But it's weak for two reasons:
>
>  * The 'state' attribute goes true when the tracepoint is enabled, but
>    stays true after the tracepoint is disabled. It only goes false when
>    the session is destroyed.
>  * It uses a private / unofficial API
>
> What I'd like is an official API that correctly evaluates whether a  
> tracepoint is enabled or not?
>
> Is this possible?

Something like:

   tracepoint_cond(provider, name, cond, ...)

might do it.

Where "cond" would be an expression (could be a statement-expression),
e.g.:

tracepoint_cond(myprovider, myevent,
        ({
                a = something;
                z = other;
                a == z;
        }),
        a, z);

So we could, in addition to perform some setup, also evaluate a
condition before calling the tracepoint. The macro might look like
(without the '\' at EOL):

#define tracepoint_cond(provider, name, cond, ...)
        do {
                if (caa_unlikely(__tracepoint_##provider##___##name.state)) {
                        if (cond)
                                
__tracepoint_cb_##provider##___##name(__VA_ARGS__);
                }
        } while (0)

So in your case, a statement-expression that evaluates to "true" would
be fine.

Note that adding support for STAP_PROBEV in there might be a bit less
straightforward, because STAP_PROBEV don't depend on the tracepoint
state.

Thoughts ?

Thanks,

Mathieu


>
> Thanks,
> Dave
>
> ----------------------------------------------------------------------
> The information contained in this transmission may be confidential. Any 
> disclosure, copying, or further distribution of confidential information is 
> not permitted unless such privilege is explicitly granted in writing by 
> Quantum. Quantum reserves the right to have electronic communications, 
> including email and attachments, sent across its networks filtered through 
> anti virus and spam software programs and retain such messages in order to 
> comply with applicable data security and retention requirements. Quantum is 
> not responsible for the proper and complete transmission of the substance of 
> this communication or for any delay in its receipt.

> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Reply via email to