Hi, On 30 July 2011 02:47, Mathieu Desnoyers <[email protected]>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
_______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
