* 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