Messages in this thread | | | Date | Mon, 22 Sep 2008 23:05:46 -0400 | From | Mathieu Desnoyers <> | Subject | Re: Unified tracing buffer |
| |
* Peter Zijlstra (a.p.zijlstra@chello.nl) wrote: > On Mon, 2008-09-22 at 09:29 -0700, Martin Bligh wrote: > > >> In conjunction with the previous email on this thread > > >> (http://lkml.org/lkml/2008/9/22/160), may I suggest > > >> the equivalent interfaces in -mm tree (2.6.27-rc5-mm1) to be: > > >> > > >> relay_printk(<some struct with default filenames/pathnames>, <string>, > > >> ....) ; > > >> relay_dump(<some struct with default filenames/pathnames>, <binary > > >> data>); > > >> and > > >> relay_cleanup_all(<the struct name>); - Single interface that cleans up > > >> all files/directories/output data created under a logical entity. > > > > > > Dude, relayfs is such a bad performing mess that extending it seems like > > > a bad idea. Better to write something new and delete everything relayfs > > > related. > > > > There did seem to be pretty universal agreement that we'd rather not > > use relayfs. > > > > > Also, it seems prudent to separate the ring-buffer implementation from > > > the event encoding/decoding facilities. > > > > Right - in conversation I had with Mathieu later, he suggested cleaning up > > relayfs - I fear this will delay us far too long, and get bogged down. > > If we can get one clean circular buffer implementation, then both > > relayfs and the tracing could share that common solution, > > Currently only blktrace and kvmtrace use relayfs, and I've heard people > talk about converting both to use lttng/ftrace infrastructure. At which > point relayfs is orphaned and ready for removal. >
LTTng sits on top of relay for buffer allocation and for the mmap operation (that's about it, it overrides the rest).
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |