Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper)

[Steven Rostedt <rostedt@goodmis.org>]

On Sat, 20 Dec 2008, Pekka Paalanen wrote:

> > 
> > To implement this at the ftrace level should be a trivial change. I'm just 
> > saying that doing this at the "ring buffer" level might be a bit more 
> > complex. The ring buffer has no idea of ftrace. It should not. It is at 
> > a lower lever than ftrace. Although, I do think some of the protecting 
> > that is done at the tracing level during resize should be moved down into 
> > the ring buffer layer.
> 
> Aah, so you are saying that the buffer_size file (or whatever it was called)
> is part of the ring buffer user API, and not tracing user API?

Nope, the buffer_size is part of the ftrace API. It was just that it 
seemed that Ingo was pushing that the ring buffer API should handle it. I 
may have misunderstood Ingo though. Note, when Ingo and I start going back 
and forth, we sometimes are at the implementation level, and probably will 
confuse the users ;-)

Since the buffer_size is at the ftrace level, it will make it easier to do 
the changes there.

> 
> But the ring buffer is just a buffer, is it meaningful to adjust a ring
> buffer size? I cannot tell tracing to go use a different buffer. And if
> there will be other users of ring buffers, they would probably want to
> have their own control over the buffer size.

Exactly.

> 
> As a user, I want to adjust *the* tracing ring buffer size, not some ring
> buffer size.

Correct, and that is what you are doing.

> 
> Am I making any sense? I'm trying to say that in my opinion, the
> buffer_size file does not belong to the "ring buffer" level. The upper
> levels should decide whether and how it offers buffer resizing.

The "buffer_size" file is part of ftrace, not the ring buffer. You are 
making perfect sense.

-- Steve