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: <1259777987.12870.70.camel@gandalf.stny.rr.com>
Date:	Wed, 02 Dec 2009 13:19:47 -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 13:06 -0500, Mathieu Desnoyers wrote:
> *
> Hrm. I wonder if having DEFINE_EVENT_CLASS is really worth having,
> considering that it really just does 2 things at once and may be
> confusing.

We keep it because that's what TRACE_EVENT currently is. It would suck
to have to replace every TRACE_EVENT there is now with a
DECLARE_EVENT_CLASS and DEFINE_EVENT. Although this would push
developers into using classes.

> 
> I would have thought amongst the lines of the following as main API
> (note: "SKETCH" is only a proposal. The idea is to do _not_ use
> declare/define, as it's really something _different_ than what people
> are expecting!)
> 
> SKETCH_EVENT_CLASS()
> 
> SKETCH_EVENT()
> 
> Which would use only DECLARE, or both DECLARE and DEFINE depending if
> CREATE_TRACE_POINTS is set. I see the DECLARE/DEFINE more as the
> "low-level" macros that are actually selected by CREATE_TRACE_POINTS:
> 
> DECLARE_EVENT_CLASS : only performs event class declarations (macros,
> inlines...)
> 
> DECLARE_EVENT : only performs event instance declarations (macros,
> inlines, ...). Depends on the DECLARE_EVENT_CLASS().
> 
> DEFINE_EVENT_CLASS : create instances of template functions.
> 
> DEFINE_EVENT : create event tracepoint functions. Depends on
> DEFINE_EVENT_CLASS().
> 
> This way, it should make digging into the generation system internals
> headhache-free. ;) I think we should really avoid re-using terms people
> are familiar with for things that have a semantic intrincially different
> than what people come to expect.

Egad No! It would make it a living nightmare. The internals reuse the
define macro, and there's no intermediate. By changing the
DECLARE_EVENT_CLASS to another name (SKETCH_EVENT_CLASS) we would have
to add something like this:

#define SKETCH_EVENT_CLASS(name, proto, args, tstruct, print) \
	DECLARE_EVENT_CLASS(name, PARAMS(proto), PARAMS(args),\
		PARAMS(tstruct), PARAMS(print))

We don't have a intermediate or "low level" macro in use here. Whatever
we give to the user is what we use.


I think the kernel developers are smart enough to figure out that these
macros are not a typical DECLARE/DEFINE that is elsewhere. But I think
using the DECLARE/DEFINE names will give them a better idea of what is
happening than to make up something completely new.

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