Messages in this thread | | | Date | Fri, 19 Dec 2008 21:56:44 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper) |
| |
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
| |