Messages in this thread | | | Date | Wed, 23 Sep 2009 17:38:34 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] introduce TRACE_EVENT_ABI (was Re: TRACE_EVENT_ABI ?) |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 2009-09-23 at 08:43 -0400, Christoph Hellwig wrote:
> > I'm not sure we can support any as an ABI yet. The text format > > seems to volatile in general - not just the output of the individual > > trace events but also the common file format, and for the binary > > format we need to figure a good way to tag the output yet. Also > > when we define one as one ABI we should make very clear what that > > means, e.g. does it have to stay exactly as is? Or can we add new > > fields but not remove old one? > > I had this discussion with people in Portland. We seem to agree that > this should just lock the old fields in, but you can add new ones at > the end.
Yeah, that's the sanest approach i was thinking about when i suggested TRACE_EVENT_ABI() to Arjan and Peter.
The raw record is opaque, comes with a length field and goes into the ring-buffer so it's nicely extensible. Existing bits shouldnt change.
User-space that relies on a record can define a structure of that and copy that over from the ring-buffer - and ignore any new bits.
What i'd also like to see is the use of typical ABI-safe type fields in the trace definitions themselves: u8, u32, u64, etc. 'long' is obviously not good. Could we do some automation for that perhaps? I.e. emit a warning (boot time or so) if TRACE_EVENT_ABI() is used with unsafe type fields.
( Endianness is another detail, if perf.data is shipped to a different-endian system. Best is probably to define a new perf.data attribute extension with the endianness of the generator system included. That way the perf.data parser can convert endianness if it wants/needs to. )
Ingo
| |