Re: [RFC PATCH 1/3] Unified trace buffer

From: Steven Rostedt
Date: Sat Sep 27 2008 - 14:18:38 EST


On Sat, 27 Sep 2008, Peter Zijlstra wrote:

> On Sat, 2008-09-27 at 13:38 -0400, Steven Rostedt wrote:
>
> > It does not even implement the merge sort. That's up to the
> > tracer to handle.
>
> You could though, as you have the timestamps..

Yep, and the first version did just that. I could add it back, but it gets
interesting if we want to read from a buffer not on the same CPU, if we
want to implement lockless.

I started (but pushed it aside) a tracing_buffer.c layer, that would do
the merges and such based on the timestamps, as well as events and event
registration. It was because of you that I pulled this stuff out of the
bottom ring buffer layer ;-)


>
> > So yes, the tracer can implement anything it wants on top of the ring
> > buffer ;-)
>
> Mathieu seems to disagree, it would be good if he can share some
> specifics so we can work on resolving those.

Mathieu always disagrees ;-)

Well the ring buffer interface should never interact directly with the
user interface. There should always be a layer between the buffer and the
user interface. This means that V2 can change drastically from V1. But I
want V1 to get in now so that we can start unifying the existing tracers
in the kernel.

Also, I like Linus's proposal that anything bigger than a page needs to be
kept outside the ring buffer and the ring buffer can simply add a pointer
to it.

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