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

[Nathan Scott]

Hi,

On 30 July 2011 02:47, Mathieu Desnoyers <mathieu.desnoyers at efficios.com>wrote:

> ...
>    ctf_float(double, field_name, argument)
>
> Makes sense ?
>
>
*nod*


> > >
> >
> > 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),
>     TP_ARGS(ts),
>     TP_FIELDS(
>           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 ?


Sounds good.

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).
>
>
*nod*


> But maybe I am missing something here ?
>

That covers it I think - higher level API does seem a workable place for
that
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.

cheers.

--
Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110801/262c4367/attachment-0002.htm>