Christoph Hellwig writes: > On Fri, Jan 14, 2005 at 04:11:38PM -0500, Karim Yaghmour wrote: > > Where does this appear in relayfs and what rights do > > user-space apps have over it (rwx). > > Why would you want anything but read access?
This would allow an application to write trace events of its own to a trace stream for instance. Also, I added a user-requested 'feature' whereby write()s on a relayfs channel would be sent to a callback that could be used to interpret 'out-of-band' commands sent from the userspace application. And if lockless logging were being used, this could provide a cheaper way for applications to write to the trace buffer than having to do it via syscall. > > > bufsize, nbufs: > > Usually things have to be subdivided in sub-buffers to make > > both writing and reading simple. LTT uses this to allow, > > among other things, random trace access. > > I think random access is overkill. Keeping the code simple is more > important and user-space can post-process it. > > > resize_min, resize_max: > > Allow for dynamic resizing of buffer. > > Auto-resizing sounds like a really bad idea. It also doesn't seem to be really useful to anyone, so we should probably remove it. Tom > > > init_buf, init_buf_size: > > Is there an initial buffer containing some data that should > > be used to initialize the channel's content. If you're doing > > init-time tracing, for example, you need to have a pre-allocated > > static buffer that is copied to relayfs once relayfs is mounted. > > And why can't you do this from that code? It just needs an initcall-like > thing that runs after mounting of relayfs. > -- Regards, Tom Zanussi <[EMAIL PROTECTED]> IBM Linux Technology Center/RAS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
