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

[fche@redhat.com (Frank Ch. Eigler)]

Hi -

On Tue, Aug 31, 2010 at 10:50:30AM -0400, Mathieu Desnoyers wrote:

> [...]  The goal of the present document is to propose a trace format
> that will suit the needs [...]. It starts by doing an overview of
> the trace format, tracer and trace analyzer requirements to consider
> for a Common Trace Format proposal.

Was it your intent to limit this document to a listing of abstract
requirements, as opposed to proposing an actual file format?


> 1) Architecture

> This high-level model is meant to be an industry-wide, common model,
> fulfilling the tracing requirements. It is meant to be application-,
> architecture-, and language-agnostic.

> [...]
> - Metadata [...]
>   - Metadata description language not imposed by standard

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?


> * 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?


> * Trace Analyzer Requirements
> [...]

Such requirements are specific to some particular tracing task.  It
would not make sense to identify these items as normative.  For
example, a trace analyzer tool that can consume the standard format
should not be deemed to violate the standard, if it merely can't grok
10GB files.


- 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/ltt-dev/attachments/20100831/89396ade/attachment.pgp>