linux-kernel - Re: [tip:perf/core] tracing: Add DEFINE_EVENT(), DEFINE_SINGLE

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: <1259773888.12870.61.camel@gandalf.stny.rr.com>
Date:	Wed, 02 Dec 2009 12:11:27 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Ingo Molnar <mingo@...e.hu>, mingo@...hat.com, hpa@...or.com,
	linux-kernel@...r.kernel.org, randy.dunlap@...cle.com,
	wcohen@...hat.com, fweisbec@...il.com, tglx@...utronix.de,
	jbaron@...hat.com, mhiramat@...hat.com,
	linux-tip-commits@...r.kernel.org, Christoph Hellwig <hch@....de>
Subject: Re: [tip:perf/core] tracing: Add DEFINE_EVENT(),
 DEFINE_SINGLE_EVENT() support to docbook

On Wed, 2009-12-02 at 11:27 -0500, Mathieu Desnoyers wrote:

> A few questions about the semantic:
> 
> Is "declare" here always only used as a declaration ? (e.g. only in
> headers, never impacted by CREATE_TRACE_POINT ?)

Well yes it is impacted by CREATE_TRACE_POINT, but so is DECLARE_TRACE
for that matter ;-)

The difference is that DECLARE_EVENT_CLASS will at most (with
CREATE_TRACE_POINT) only create the functions that can be used by other
events. It does not create an event itself. That is, it's not much
different than making a "static inline function" except that function
will not be static nor will it be inline ;-)

> 
> Is "define" here always mapping to a definition ? (e.g. to be used in a
> C file to define the class or event handling stub)

The DEFINE_* will create something that can be hooked to the trace
points in other C files.

> 
> I feel that your DEFINE_EVENT_CLASS might actually be doing a bit more
> than just "defining", it would actually also perform the declaration.
> Same goes for "DEFINE_EVENT". So can you tell us a bit more about that
> is the context of templates ?

Well, the macros used by these are totally off the wall anyway :-) So
any name we come up with will not match what the rest of the kernel does
regardless. But we need to give something that is close.

I'm liking more the:

DECLARE_EVENT_CLASS, DEFINE_EVENT, DEFINE_EVENT_CLASS, because I think
that comes the closest to other semantics in the kernel. That is (once
again)

DECLARE_EVENT_CLASS - makes only the class. It does create helper
functions, but if there's no DEFINE_EVENT that uses them, then they are
just wasting space.

The DEFINE_EVENT will create the trace points in the C file that has
CREATE_TRACE_POINTS defined. But it requires the helper functions
created by a previous DECLARE_EVENT_CLASS.

DEFINE_EVENT_CLASS will do both create a EVENT_CLASS template, as well
as a EVENT that uses the class. The name of the class is a separate
namespace as the event. Here both the class and the event have the same
name, but other events can use this class by referencing the name.

DEFINE_EVENT_CLASS(x, ...);

DEFINE_EVENT(x, y, ...);

The DEFINE_EVENT_CLASS will create a class x and an event x, then the
DEFINE_EVENT will create another event y that uses the same class x.

Actually, with the above, we may not need to have DECLARE_EVENT_CLASS()
at all, because why declare a class if you don't have an event to use
it?  But then again, you may not want the name of the class also a name
of an event.

-- Steve

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