[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091202144334.GA30359@elte.hu>
Date: Wed, 2 Dec 2009 15:43:34 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: mingo@...hat.com, hpa@...or.com, mathieu.desnoyers@...ymtl.ca,
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
* Steven Rostedt <rostedt@...dmis.org> wrote:
> On Wed, 2009-12-02 at 15:01 +0100, Ingo Molnar wrote:
>
> > > DECLARE_CLASS_AND_DEFINE_EVENT()
> >
> > Hm, that's a bit too long. How about 'DEFINE_CLASS_EVENT()' as a
> > compromise? It's similarly short-ish to TRACE_EVENT(), and it also
> > conveys the fact that we create both a class and an event there.
> >
> > The full series would thus be:
> >
> > DECLARE_EVENT_CLASS
> > DEFINE_EVENT
> > DEFINE_CLASS_EVENT
> >
> > hm?
>
> I thought about that too, but it actually makes it more confusing.
> Because, looking at this with a fresh POV, I would think that after I
> declare a class, I would use DEFINE_CLASS_EVENT with that class.
yeah. Hence was my second-best choice 'DEFINE_STANDALONE_EVENT' or
'DEFINE_SINGLE_EVENT' - to stress the special nature it, and to actually
nudge people towards creating classes of events instead of doing
separate, standalone points. (which are a waste in the majority of
cases)
Ingo
--
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/
Powered by blists - more mailing lists