* David Bryant ([email protected]) 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
> [email protected]
> 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
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
