Re: [PATCH 0/6] ftrace: port to the new ring_buffer

[Ingo Molnar <mingo@elte.hu>]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> These patches are against linux-tip.
> 
> The first is just a fix in the wakeup selftest.
> 
> The next is a port of the Unified tracer buffer to linux-tip and some 
> updates.
> 
> After that is the ftrace port to use the ring buffer, followed by some 
> more enhancements to ftrace because of the new variable length buffer.
> 
> I tried a few configurations and tried to test all the different 
> ftrace tracers, but I'm sure there may be some bugs still to work out. 
> I worked out all those that I found.

very nice! I'd expect breakages and complications too so i restructured 
tip/tracing/* a bit: firstly i created a tip/tracing/core append-only 
merge branch which collects all the known-robust bits. Then i created a 
new branch for your new generic ring-buffer feature: 
tip/tracing/ring-buffer, and applied your patches. I've started testing 
it.

Once we declare it OK, it can be merged into tip/tracing/core.

> But, with the ring_buffer I can envision several ways to clean up 
> ftrace and to make adding new tracers cleaner.
> 
> I'm also thinking about making a way that each tracer can allocate its 
> own buffer, and allow for more than one tracer to be running at the 
> same time! (only with different buffers).

yeah. Ideally this should just fall out of the generic framework - i.e. 
tracer plugins should not have to do anything extra to get per tracer 
buffers. They should just add their own specialistic flavor, there 
should be no repetitions otherwise. (barring cases where a tracer wants 
to deviate from default behavior)

	Ingo