[ltt-dev] [RFC] New UST 2.0 Tracepoint Event API
nathans at debian.org
Mon Aug 1 06:17:44 EDT 2011
On 30 July 2011 02:47, Mathieu Desnoyers <mathieu.desnoyers at efficios.com>wrote:
> ctf_float(double, field_name, argument)
> Makes sense ?
> > >
> > In addition to the type information that the format string provides,
> > it could also be very useful for a consumer tool to be able to tell
> > the units of the trace data - bytes, kilobytes, milliseconds,
> > nanoseconds, etc. Not sure I can think of a neat way to add that into
> > the API though - perhaps extending the format string with optional
> > type decorator? Might be a bit counter-intuitive/ugly.
> The way we could see doing this with the current infrastructure is to
> end the field labels with units, e.g.:
> TRACEPOINT_EVENT(< [com_company_]project_[component_]_event >,
> TP_PROTO(struct timespec ts),
> ctf_integer(typeof(ts.tv_sec), time_seconds, ts.tv_sec)
> ctf_integer(typeof(ts.tv_nsec), time_nanoseconds, tv.tv_nsec)
> So far, I am not planning to support "format strings" within the events:
> the idea is that the field names should be sufficient to identifiy the
> associated data, and it leaves more room for formatting to the trace
> analysis tools.
> Thoughts ?
I'm thinking of adding this as a higher-level: e.g. a function tracer
> could choose to suffix the function names with _entry and _return
> suffix, and the trace analysis tool would be aware that those match. I
> don't see much benefit in forcing these pairs at the instrumentation
> level though, as this can be done by the instrumented system. Also, we
> need to take nesting and preemption into account when we present these
> pairs, so I kind of doubt we can reliably present all "begin/end" pairs
> with just a simple pre-defined suffix: the trace analyser will need to
> be aware of the context (e.g. get the thread ID context with each event
> to know to which thread the begin/end pairs belong, and also keep a
> nesting counter of begin/end pairs to match the pairs together).
> But maybe I am missing something here ?
That covers it I think - higher level API does seem a workable place for
kind of functionality.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lttng-dev