Re: [RFC/Requirements/Design] h/w error reporting

[Steven Rostedt]

On Wed, 2010-11-10 at 16:30 +0100, Peter Zijlstra wrote:

> As for the buffer, I prefer a u64 aligned data stream, but the very
> least I need is frame encapsulation. What I don't want _ever_ is stupid
> sub-buffers. And no they're not needed, see the discussion about sync
> markers a while back.

BTW, the sub buffers is just an implementation detail. I suspect that
we'll have to end up with something that splits the buffer up. Whether
we have 'markers' or something else. They all break down the buffer into
a "sub-buffer".

> 
> I also don't want to support the stupid concurrent read/write from tail.

I was thinking about this more. I guess it can work if the reader always
goes the opposite direction of the writer. It's just any user that uses
this will need to cope with it. I would personally like both methods
implemented. One as the "broken design" (as you put it) which removes
the burden of sorting from the user. But the "fast design" which
requires the end result having to be able to sort the buffer.

> 
> What I do want is both mmap() and splice(), this means buffer size needs
> to be specified at buffer creation.

Sure.

> 
> I currently support overwrite (flight-recorder) and non-overwrite modes
> depending on PROT_WRITE, I guess that can easily be pushed into the
> buffer create call.

yep.

> 
> As to the mmap() part, it needs a control page to expose the head/tail
> pointers and some data.

But lets make this somehow generic, where it can be used by all sorts.


> And as you know I need to write > PAGE_SIZE entries.

Sure.

Also, lets not focus now on implementation. Let's try to concentrate on
what we want the tools to be able to do.

For example, I would like:

Very small entries, and pick and chose what I want in my entries.

A way to read it fast to a file or over the network (splice).

The read backwards seems like a cool idea, but I would not want to throw
away the read forwards part either.

How we implement this, we can work together on.

-- Steve


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