[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091126192019.GA11245@elte.hu>
Date: Thu, 26 Nov 2009 20:20:19 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>, mingo@...hat.com,
hpa@...or.com, linux-kernel@...r.kernel.org,
penberg@...helsinki.fi, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org, Christoph Hellwig <hch@....de>
Subject: Re: [tip:perf/core] events: Rename TRACE_EVENT_TEMPLATE() to
DECLARE_EVENT_CLASS()
* Steven Rostedt <rostedt@...dmis.org> wrote:
> (added Christoph since he was the one to recommend the template
> creation)
>
> On Thu, 2009-11-26 at 19:12 +0100, Ingo Molnar wrote:
> > * Frederic Weisbecker <fweisbec@...il.com> wrote:
>
> > DECLARE_EVENT_CLASS() doesnt really define an event visible to the user
> > yet though. It defines functions internally (to be used by the real
> > definition of the event) - but not visible externally really.
> >
> > So the real 'definition' of an event happens with DEFINE_EVENT() - in
> > the logical model of this.
> >
> > So the logical model is clear:
> >
> > DECLARE_EVENT_CLASS(class);
> >
> > DEFINE_EVENT(class, event1);
> > DEFINE_EVENT(class, event2);
> > DEFINE_EVENT(class, event3);
> > ...
> >
> > # later:
> > # DEFINE_STANDALONE_EVENT(event)
>
> I think that name sounds even uglier than DEFINE_SINGLE_EVENT :-/
>
> I'm fine with the DECLARE_EVENT_CLASS and DEFINE_EVENT, but I'm unsure
> what to rename TRACE_EVENT as. I know its still pretty new, but it's
> being used quite a bit. So it should take some extra thought.
>
> I guess DEFINE_EVENT_CLASS is probably not good, although this would
> be the combination of DECLARE_EVENT_CLASS and DEFINE_EVENT which it
> actually is.
>
> DECLARE_DEFINE_EVENT? *naw*
>
> DEFINE_DECLARED_EVENT?
>
> Or we could go with DECLARE_EVENT(), DECLARE_EVENT_CLASS() and
> DEFINE_EVENT_CLASS_INSTANCE()?
I think the most common one should be the shortest, and the most common
one will be DEFINE_EVENT() - that's short enough already IMO.
I think we generally want to encourage the creation of classes of
events, not myriads of standalone events, each with their own call
signature, record format and printouts.
In that sense making the TRACE_EVENT() one longer would achieve that
goal of discouraging its over-use: DEFINE_SINGLE_EVENT() tells the
developer that it's an event of it's kind.
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