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 for Android: free password hash cracker in your pocket

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

Message-ID: <20081231205708.4ee8b141@iki.fi>
Date:	Wed, 31 Dec 2008 20:57:08 +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 Wed, 31 Dec 2008 13:33:19 -0500 (EST)
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Wed, 31 Dec 2008, Pekka Paalanen wrote:
> > 
> > "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. :-)
> 
> 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?
Are we controlling an action (recording events), a feature (a buffer
where to record) or an implementation (a ring buffer)?
Does the user know or care if it is a ring buffer or just whatever
temporary storage?
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'm sure we could discuss this forever, so I'll just say:
Happy new year! :-)

-- 
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/