Re: [RFC PATCH 1/3] Unified trace buffer

[Steven Rostedt]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/