Re: ftrace behaviour (was: [PATCH] ftrace: introducetracing_reset_online_cpus() helper)

From: Steven Rostedt
Date: Wed Dec 31 2008 - 14:06:38 EST



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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/