Messages in this thread | | | Date | Thu, 1 Jan 2009 00:08:12 +0200 | From | Pekka Paalanen <> | Subject | Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper) |
| |
On Wed, 31 Dec 2008 14:06:26 -0500 (EST) Steven Rostedt <rostedt@goodmis.org> wrote:
> 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?
To me "record" sounds more of a noun than a verb, but it's both and I'm not a native speaker. Still, it brings me to "recording_enabled", and do we really need the "_enabled" part? So we end up to what I suggested earlier: "recording" with values 0 and 1. :-)
Anyway, it's good to start the file name with a few distinct letters, it makes tab-completion so much easier on the command line.
> > 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.
-- Pekka Paalanen http://www.iki.fi/pq/
| |