[ltt-dev] [RFC] New UST 2.0 Tracepoint Event API

[Mathieu Desnoyers]

* Aaron Spear (aspear at vmware.com) 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.
> 
> Hi Mathieu. A couple of questions at this point: 

Hi Aaron,

> 1) would the loglevel be inserted into every event as an additional
> attribute? As what, an integer? 

I plan to add this loglevel information into the metadata describing
each event, so we don't have to repeat the information in the binary
trace stream. In terms of CTF, we'd have:

event {
  name = some_event; 
  loglevel = [ enumeration value OR integer ];
  fields := struct { ... };
};

> 2) Would you leave the interpretation and allowable values for
> "loglevel" open ended? It seems like that could be used for different
> levels of verbosity (but perhaps that is what "debug" is, verbose? 

Yep. The idea here is that we could have e.g. an enumeration defined in
the metadata, and use it directly within the metadata:

enum {
	LOGLEVEL_PRINTER_ON_FIRE,
	LOGLEVEL_ERROR,
	LOGLEVEL_WARNING,
	LOGLEVEL_INFO,
	LOGLEVEL_DEBUG,
	LOGLEVEL_SPAM,
};

event {
  name = some_event; 
  loglevel = LOGLEVEL_WARNING;
  fields := struct { ... };
};

In terms of babeltrace implementation, we'd have to adapt the current
codee slightly so we teach the intermediate representation generator to
recognise the enumeration tokens (it currently does not have to).

> 3) would it be possible to filter/disallow tracing of events
> dynamically based on the log level? I have done this a few times in
> the past in various systems I have designed. 

Certainly, that's one of the intended uses.

Thanks,

Mathieu

> 
> cheers, 
> Aaron Spear 

> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


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