Re: [PATCH] Re: relayfs documentation sucks?

[Tom Zanussi <zanussi@us.ibm.com>]

bert hubert writes:
 > On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
 > 
 > > It is racey - in this mode, there's nothing to keep the kernel from
 > > writing as much as it wants before the user side has a chance to read
 > > any of it.  The only way this can be used safely is to make sure the
 > > kernel side isn't writing anything when the client is reading.  This
 > > would be typical of a flight-recording usage i.e. kernel writes a
 > > bunch of data continuously, then stops and allows the client to read
 > > whatever's in there.
 > 
 > Or by numbering entries written out, when in flight-recording mode you
 > wouldn't want to block the kernel.
 > 
 > >  > In fact, it appears this might even happen in non-overwrite mode.
 > > 
 > > It shouldn't ever be able to happen in non-overwrite mode - if it
 > > did, it would be a bug.  Can you be more specific as to how you see
 > > this happening in this mode?
 > 
 > Yeah - you're right. The misunderstanding is because in both cases
 > (overwrite and non-overwrite) data is lost, except that in one case you lose
 > old data, and in the other new data.

Just to clarify - in either mode, if you don't have a consumer or the
consumer can't keep up with the amount of data being written by the
kernel, you will of course lose data at some point.  Normally you
wouldn't want to lose data; by using non-overwrite mode you're
implicitly letting relayfs know this i.e. if at any point all the
sub-buffers remain unread and the kernel is still trying to write into
them, let the client know (via the buffer-full callback) that this has
happened.  Presumably you would then increase the buffer size or have
the kernel write less etc.

 > 
 > It might be a good idea to document this as well.
 > 

Yes, I'll make it more explicit in the documentation.

 > Btw, I've already uncovered interesting things using relayfs, but I still
 > don't see the case for having it merged :-)

Glad to hear it.  Can you say what if anything would convince you it
should be merged?

 > 
 > Thanks for your answers, I think I get it all now.

No problem, and thanks for patch and other suggestions.

Tom


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