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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.10.0809241731020.10631@gandalf.stny.rr.com>
Date:	Wed, 24 Sep 2008 17:33:43 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
cc:	Martin Bligh <mbligh@...gle.com>,
	David Miller <davem@...emloft.net>,
	torvalds@...ux-foundation.org, peterz@...radead.org,
	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
	akpm@...ux-foundation.org, prasad@...ux.vnet.ibm.com,
	compudj@...stal.dyndns.org, dwilder@...ibm.com, hch@....de,
	zanussi@...cast.net, srostedt@...hat.com
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

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