[lttng-dev] babeltrace

[Simon Marchi]

On 8 May 2014 03:00, Alexandre Montplaisir <alexmonthy at voxpopuli.im> wrote:
> Hi,
>
> Every event type has different fields though. So the "columns" would
> vary from one event to another.
>
> Although I can see that if you add let's say "context.pid" to ALL
> events, then it would be nice in the CSV export to add this as a
> separate column. However, the viewer cannot know for sure that all
> events in the trace have that particular context enabled. Unless you do
> a full pass of the trace first to look for common fields.
>
> Or, you do a first pass to check for all possible existing fields in the
> trace, and add all of those as separate columns. Then you write the
> event information in the relevant columns only, and you end up with a
> CSV with a lot of "holes".

To avoid doing a complete first pass of the trace, you can just
iterate on the event types as described in the metadata, and take note
of all the possible field you can find in the trace. Then, during your
only pass, you already know all your "columns".

As you say, traces such as kernel traces would not play well with a
format based on fixed columns, as most space would be emtpy. It can
make sense if it is your own trace (a userspace trace) and you know
that all events contain more or less the same fields.

> It would be possible to hack ExportToTextRequest.java to have any
> particular behavior. But I'm not sure how this option could be
> implemented and exposed to the user generically.

I think that the babeltrace Python bindings are much better suited for
something like this than TMF though. This can probably be done in a
20-30 lines script.

Simon

> Cheers,
> Alexandre