Messages in this thread | | | Date | Wed, 24 Sep 2008 17:33:43 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: [RFC PATCH 1/3] Unified trace buffer |
| |
On Wed, 24 Sep 2008, Frank Ch. Eigler wrote:
> Hi - > > On Wed, Sep 24, 2008 at 01:51:55PM -0700, Martin Bligh wrote: > > [...] > > One thing we said we could do is compile the "decompaction" tools > > along with the kernel, in the kernel tree. Then if we change the in-kernel > > format, you don't break all the userspace tools. > > If the common tracing idea still includes kernel-supplied ASCII as an > alternative to binary (so that one could grep some debugfs file), then > it would be nice to have some common code for decoding the trace > records offline. > > If we can associate a simple specific struct type ("struct > ftrace_event") with each trace id type in an object-code-resident > table, we could automate some of this. The kernel build process could > sniff dwarf data (a la acme's struct-layout-printing dwarves) at or > before modpost time to generate a snippet of C code for each such > event struct. That C code could be the generic ASCII-printing > callback for use by debugfs. A variant could be a userspace-usable > version. Given the same id-to-struct-name mapping, Sytemtap could > expose event records field by field, by name.
Hi Frank,
I think we are going a step below this. That is, the ring buffer itself will not be expecting to expose anything to the user interface.
That will need to be done in a higher layer. Right now we just want a way to stabilize the ring buffer infrastructure. Then we can add a tracing infrastructure on top that can do the above work.
I'm working on having a ring_buffer.c that will do the bare minimum, and a trace_buffer.c that will be a layer on top that will add more functionality. What you are asking for may apply there.
Thanks,
-- Steve
| |