Re: 2.6.11-rc1-mm1

[Tom Zanussi]

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 <zanussi@xxxxxxxxxx>
IBM Linux Technology Center/RAS

-
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/