lkml.org 
[lkml]   [2005]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Merging relayfs?
From
Date
On Sun, 2005-07-17 at 10:52 -0500, Tom Zanussi wrote:

> >
> > > > - overwrite mode can be implemented via the buffer switch callback
> > >
> > > The buffer switch callback is already where this is handled, unless
> > > you're thinking of something else - one of the first checks in the
> > > buffer switch is relay_buf_full(), which always returns 0 if the
> > > buffer is in overwrite mode.
> >
> > I mean, relayfs doesn't has to know about this, the client itself can do
> > it (e.g. via helper functions).
>
> In a previous version, we did something like having the client pass
> back a return value from the callback indicating whether or not to
> continue or stop. I can try doing something like that instead again.

Tom,

I'm actually very much against this. Looking at a point of view from the
logdev device. Having a callback to know to continue at every buffer
switch would just be slowing down something that is expected to be very
fast. I don't see the problem with having an overwrite mode or not. Why
can't relayfs know this? It _is_ an operation of relayfs, and having it
pushed to the client would seem to make the client need to know more
about how relayfs works that it needs to. Because, the logdev device
doesn't care about buffer switches.

-- Steve


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

\
 
 \ /
  Last update: 2005-07-18 15:48    [W:0.077 / U:0.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site