Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [ltt-dev] [RFC] New UST 2.0 Tracepoint Event API
Date: Wed, 31 Aug 2011 10:38:17 -0400	[thread overview]
Message-ID: <20110831143817.GA11066@Krystal> (raw)
In-Reply-To: <BLU0-SMTP952D5E28B173886307A86596200@phx.gbl>

* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> * Nathan Scott (nathans at debian.org) wrote:
> [...]
> > > I was also wondering if putting a "loglevel" information (could be
> > > optional) into the TRACEPOINT_EVENT declaration would be useful ? This
> > > could define log levels such as debug, info, warning, and error.
> > >
> > 
> > I think that'd be useful - ETW does this on Windows, FWIW.
> > Being able to enable/disable these sub-classes of events is probably useful
> > and it shows the programmers general intent with each event too.
> 
> Hrm, I thought about this loglevel idea a little more, and it does not
> seem like it belongs directly into TRACEPOINT_EVENT(). Although tracing
> *can* do logging, tracing is not logging. Therefore, it makes no sense
> to require information that is logging-specific to be declared for all
> tracepoints.
> 
> I foresee that we could eventually add API members to support loglevels
> defined alongside with the tracepoint instrumentation, e.g.:
> 
> TRACEPOINT_LOGLEVEL_ENUM(
> 	TP_LOGLEVEL(TP_LOG_DEBUG, 0),
> 	TP_LOGLEVEL(TP_LOG_WARN, 1),
> 	...
> )
> 
> TRACEPOINT_EVENT(
> 	some_tp_name,
> 	rest of standard tracepoint declaration, without any loglevel
> 	whatsoever...
> )
> 
> TRACEPOINT_LOGLEVEL(some_tp_name, TP_LOG_DEBUG)
> 
> With this, libust could export the application loglevels, along with the
> event name to loglevel mappings. I don't plan to implement this API
> right now though.
> 
> Thoughts ?

I have a client who would like this API to appear in UST 2.0 headers
soon so they can use it in their instrumentation (even before those
macros are actually implemented). So I think it makes sense to settle on
this:

#ifndef TRACEPOINT_LOGLEVEL

/*
 * Tracepoint Loglevel Declaration Facility
 *
 * This is a place-holder the tracepoint loglevel declaration,
 * overridden by the tracer implementation.
 *
 * Typical use of these loglevels:
 *
 * 1) Declare the mapping between loglevel names and an integer values
 *    within TRACEPOINT_LOGLEVEL_ENUM, using TP_LOGLEVEL for each tuple.
 *    Do _NOT_ add comma (,) nor semicolon (;) between the
 *    TRACEPOINT_LOGLEVEL_ENUM entries. Do _NOT_ add comma (,) nor
 *    semicolon (;) after the TRACEPOINT_LOGLEVEL_ENUM declaration.  The
 *    name should be a proper C99 identifier.
 *
 *      TRACEPOINT_LOGLEVEL_ENUM(
 *              TP_LOGLEVEL( < loglevel_name >, < value > )
 *              TP_LOGLEVEL( < loglevel_name >, < value > )
 *              ...
 *      )
 *
 *    e.g.:
 *
 *      TRACEPOINT_LOGLEVEL_ENUM(
 *              TP_LOGLEVEL(LOG_EMERG,   0)
 *              TP_LOGLEVEL(LOG_ALERT,   1)
 *              TP_LOGLEVEL(LOG_CRIT,    2)
 *              TP_LOGLEVEL(LOG_ERR,     3)
 *              TP_LOGLEVEL(LOG_WARNING, 4)
 *              TP_LOGLEVEL(LOG_NOTICE,  5)
 *              TP_LOGLEVEL(LOG_INFO,    6)
 *              TP_LOGLEVEL(LOG_DEBUG,   7)
 *      )
 *
 * 2) Then, declare tracepoint loglevels for tracepoints. The first
 *    field is the name of the tracepoint, the second field is the
 *    loglevel name.
 *
 *      TRACEPOINT_LOGLEVEL(< [com_company_]project_[component_]event >,
 *              < loglevel_name >)
 *
 * The TRACEPOINT_SYSTEM must be defined when declaring a
 * TRACEPOINT_LOGLEVEL_ENUM and TRACEPOINT_LOGLEVEL. The tracepoint
 * loglevel enumeration apply to the entire TRACEPOINT_SYSTEM. Only one
 * tracepoint loglevel enumeration should be declared per tracepoint
 * system.
 */

#define TRACEPOINT_LOGLEVEL_ENUM()
#define TRACEPOINT_LOGLEVEL(name, loglevel)

#endif /* #ifndef TRACEPOINT_LOGLEVEL */


So although I cannot say with a 100% confidence level that this will not
change when I will implement the actual macros (planned for this Fall),
I am fairly confident we should be fine with this API.

Feedback is, as always, welcome.

Thanks,

Mathieu

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




       reply	other threads:[~2011-08-31 14:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110727190601.GA27545@Krystal>
     [not found] ` <CAAp5ZgMyb_ZaRfkEcXCVBg_+Jbs85sds_mpBvC7aEqD9G4iMMA@mail.gmail.com>
     [not found]   ` <20110729164755.GA10790@Krystal>
     [not found]     ` <CAAp5ZgNnnKAWfqz6Edim0Qgd0Mjwym3tFKNx-vOPO53cjRnGyg@mail.gmail.com>
     [not found]       ` <BLU0-SMTP952D5E28B173886307A86596200@phx.gbl>
2011-08-31 14:38         ` Mathieu Desnoyers [this message]
2011-09-01  9:50           ` Nathan Scott
2011-09-01  9:50             ` Nathan Scott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110831143817.GA11066@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox