[ltt-dev] [RFC] Common Trace Format Requirements (v1.3)

[Frank Ch. Eigler]

Hi -

On Tue, Aug 31, 2010 at 12:37:22PM -0400, Mathieu Desnoyers wrote:

> [...]  Yep. But I'm trying to state the requirements as clearly as
> possible so I can leave the justification out of the trace format
> proposal per se.

Doing it this way is somewhat risky, since people who agree in general
with the abstract requirements may change their minds once a specific
design is presented.  So, expect the rationale to be a part of the
debate once the proposed format is shown.


> I'm also only planning to do a proposal for a Linux-specific trace
> format, which can be seen as a single instance of the trace format
> model.

(How different do you expect a non-linux-specific "standard" trace
format to be?)


> > If the metadata is not given in a standard form, then how do envision
> > general trace analysis tools (those not hard-coded for some particular
> > trace source) working?

> We can have a metadata format selector at the beginning of the
> metadata section, with reserved IDs for metadata formats. We can
> think of a format generated natively by TRACE_EVENT(), a format
> generated in some sort of XML. The trace analyzer would need the
> metadata format parser in order to be able to read the trace.

If one hopes that such tools should be able to consume data with
drifting versions of TRACE_EVENT() or XML or whatnot, they themselves
had better be fixed/standardized.  Otherwise, the data will not be
self-describing, and all the tools will have to chase
kernel/etc. versions.


> > > * Requirements on the Tracers
> > 
> > > Higher-level tracer requirements that seem appropriate to support
> > > some of the trace format requirements stated above.  [...]
> > 
> > The list that follows here appear to be wish-list performance
> > characteristics of the tracing infrastructure ("make it go fast" and
> > "use good transports").  How does it benefit the tracing *format*
> > specification to enumerate such particulars here?

> Requirements like tracer speed influences the format in many ways, e.g.:

> - requirement for compactness leads to schemes where all information
> repetition should be eliminated. Thus the need for optional
> per-section context information.

> - requirement for speed and streaming leads to zero-copy
> implementations, which imply that the trace format should be written
> natively by the tracer.

Not exactly: the requirements of high speed influence the trace format
to the extent that it must be *possible* to write it at a high speed.
The format cannot mandate that it *necessarily* be written in a
zero-copy way, or without intermediate transformations.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100831/f6165975/attachment-0003.pgp>