Messages in this thread |  | | | Subject | Re: Unified tracing buffer | | From | Peter Zijlstra <> | | Date | Mon, 22 Sep 2008 18:36:41 +0200 |
| |
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.
|  |