Messages in this thread | | | Date | Sat, 27 Sep 2008 14:18:25 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: [RFC PATCH 1/3] Unified trace buffer |
| |
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
| |