lkml.org 
[lkml]   [2008]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper)

On Wed, 31 Dec 2008, Pekka Paalanen wrote:

> >
> > Since this really only enables or disables the ring buffer, perhaps
> > "ringbuffer_enabled" is the way to go?
>
> As a C-function or as a debugfs file?

I was thinking of only changing the debugfs file.

> Are we controlling an action (recording events), a feature (a buffer
> where to record) or an implementation (a ring buffer)?

Good point. It only disables the recording, so perhaps a "record_enabled"
would be better?

> Does the user know or care if it is a ring buffer or just whatever
> temporary storage?

Yeah, the user does not know or care what the implementation is.

> What does the user actually want to control? A buffer? A ring
> buffer? Recording stuff? The tracer? Tracing? Data flow?
> Assuming there are also other users than tracing, does it make
> sense to control the ring buffer facility itself?

I think the name record_enabled for debugfs is the best. This is exactly
what happens (not how it is implemented). When someone echos 0 to
record_enabled (currently called tracing_on), it stops the recording, and
nothing else. The tracers still try to write to the buffer, but the write
always fails. This does not disable the tracers or even notify the tracer
that the buffers have stopped recording. This is just a simple light
weight way to stop and start recording to the trace buffers from either
user space or kernel space. Kernel space can stop it, and user space can
start it again (that was the original request for this feature).

I'm leaning towards record_enabled now.

>
> I'm sure we could discuss this forever, so I'll just say:
> Happy new year! :-)

I still have 10 more hours, but who cares? ;-)

Happy New Year to you too!

-- Steve



\
 
 \ /
  Last update: 2008-12-31 20:09    [W:0.120 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site