Re: Merging relayfs?

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 2005-07-12 at 03:25 +0100, Christoph Hellwig wrote:
> On Mon, Jul 11, 2005 at 08:10:42PM -0500, Tom Zanussi wrote:
> > 
> > Hi Andrew, can you please merge relayfs?  It provides a low-overhead
> > logging and buffering capability, which does not currently exist in
> > the kernel.
> 
> While the code is pretty nicely in shape it seems rather pointless to
> merge until an actual user goes with it.
> 

I have to also say that this is an exception.  How many people out there
have written a variant of relayfs to do debugging?  It is about time
that there's a buffer in the kernel that can be written to and later
retrieved to debug things like the scheduler that printk in all its
forms just doesn't cut it.

I've been working with Tom to get my logdev debugging tool to use
relayfs as a back end.  This allows for showing output that shows
exactly what's going on inside the kernel. It keeps the latest data
around and when/if the kernel crashes, it shows all the events that lead
up to the crash.  Well, it doesn't automatically show what has happened,
but you can put print like statements anywhere in any context and the
latest will be dumped on command or a NMI/panic/oops or whatever.

Once relayfs is added, we need to make a buffer that can be written to
from multiple CPUS.  I understand that Tom got complaints that the
buffers were not orignally lockless, and different CPUs would have their
own buffers.  But this really hurts trying to debug race conditions on
SMP machines, since you don't get the interleaved output of what's going
on.  God I need to get KCSP working, and not worry about race conditions
anymore! :-)

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