Re: Merging relayfs?

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 2005-07-18 at 16:16 +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 18 Jul 2005, Steven Rostedt wrote:
> 
> > 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.
> 
> What exactly would be slowed down?
> It would just move around some code and even avoid the overwrite mode 
> check.

Yes, you're adding a jump to another function via a function pointer,
that would kill the cache line of execution, to avoid a simple check, or
some other way of handling it. Since I don't want to know the internals
of relayfs, the overwrite mode could be implemented in a more officient
way. Granted, this probably isn't much of a slowdown since the copying
of data would be much longer.

> 
> > I don't see the problem with having an overwrite mode or not. Why
> > can't relayfs know this?
> 
> The point is to design a simple and flexible relayfs layer, which means 
> not every possible function has to be done in the relayfs layer, as long 
> it's flexible enough to build additional functionality on top of it (for 
> which it can again provide some library functions).

The overwrite mode isn't that complex.  You don't want to make something
so flexible that it becomes more complex.  Assembly is more flexible
than C but I wouldn't want to code a lot with it.  A library function
for me is out of the question, since what I build on top of relayfs is
mostly in the kernel.  The overwrite mode would then have to be
implemented through another kernel activity.  I might as well keep my
own ring buffers and forget about using relayfs, and all my points in
which I argue for it being merged is mute.

-- Steve