From mboxrd@z Thu Jan 1 00:00:00 1970 From: fche@redhat.com (Frank Ch. Eigler) Date: Tue, 31 Aug 2010 13:04:53 -0400 Subject: [ltt-dev] [RFC] Common Trace Format Requirements (v1.3) In-Reply-To: <20100831163722.GA27279@Krystal> References: <20100831145030.GA18176@Krystal> <20100831153650.GI3185@redhat.com> <20100831163722.GA27279@Krystal> Message-ID: <20100831170453.GA5762@redhat.com> Message-ID: <20100831170453.dRa3mclRImclM8VQOE9XV6H-rmM-gEszUn6ff_B0JBg@z> 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: