linux-kernel - Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081231155325.392699d0@iki.fi>
Date:	Wed, 31 Dec 2008 15:53:25 +0200
From:	Pekka Paalanen <pq@....fi>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Frédéric Weisbecker <fweisbec@...il.com>,
	Pekka J Enberg <penberg@...helsinki.fi>, mingo@...e.hu,
	linux-kernel@...r.kernel.org,
	Markus Metzger <markus.t.metzger@...il.com>
Subject: Re: ftrace behaviour (was: [PATCH] ftrace: introduce
 tracing_reset_online_cpus() helper)

On Fri, 19 Dec 2008 21:47:53 -0500 (EST)
Steven Rostedt <rostedt@...dmis.org> wrote:

> > > The tracing_enabled is the way to start and stop a trace. I'm considering 
> > > to implement Frederic's request to reset the buffer on enabled. This is 
> > > quick but requires locks and mutexes to be taken. It calls a hook to the 
> > > plugin because different plugins actually want to reset (the irq latency 
> > > tracers reset with this).
> > > 
> > > The tracing_on is something that has been asked by developers to give a 
> > > way to start and stop tracing fast as possible, with no mutexes or added 
> > > locks. In fact, this option is local to the ring buffer code. Ftrace does 
> > > not even use it directly.  It just a global flag to stop tracing. There's 
> > > also an in-kernel equivalent tracing_on() and tracing_off(). This just 
> > > sets or clears a global flag that will stop any more writes to the trace 
> > > buffer.
> > 
> > Why not call tracing_on, say, logging_enabled?
> > IMHO tracing_enabled vs. tracing_on is incomprehesible, but
> > tracing_enabled vs. logging_enabled is a little more understandable.
> > current_tracer is self-explanatory, and tracing_enabled used to be.
> 
> One of the hardest things about ftrace is coming up with good naming. This 
> is not always so easy, as you can tell. I'm not sure "logging_enabled" is 
> any better. That would confuse myself ;-)   The reason I chose "on" is 
> because it is like an on/off switch, where as enabled/disabled is usually 
> (in the kernel anyway) associated to nesting.
> 
> How about tracing_enabled_light? ;-)

"tracing_on" is not a function call, so nesting does not make sense.
It is a file in debugfs, and therefore an end user interface. I am only
talking about the debugfs files, not functions. Only developers use
functions and devels can be expected to find the implementation and
read the fine documentation.

How about /debug/tracing/recording with values 0 and 1?
That would be a clear distinction to /debug/tracing/tracing_enabled.
I have also wondered about the "tracing_" prefix, the files are
already in the tracing/ directory.

I am just trying to think what file names would make sense in
debugfs. I completely agree with you on function naming, but should
the file have the same name as the function? Sure, for developers
it would be easier to remember, but the name might not make any
sense unless you know the internal implementation.

If something else than tracing starts to use the ring buffer
facility, we have to think about the names again. Until then,
just my 2c. :-)


Thanks.

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