Messages in this thread | | | Date | Wed, 23 Sep 2009 12:16:34 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [patch] introduce TRACE_EVENT_ABI (was Re: TRACE_EVENT_ABI ?) |
| |
* Ingo Molnar (mingo@elte.hu) wrote: > > * 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. ) >
You can ship sizeof(long) along with the endianness information to access "long" typed variables from the parser too. If we export this information, then I don't see how exporting a 'long' variable would be obviously not good. It would become as portable as u32 or u64, yet more efficient when only the space for a 'long' record is required. Same applies to pointers, obviously.
All we need is a small "accessor" library to deal with the type size and endianness issues.
Mathieu
> Ingo
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |