All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
	mingo@redhat.com, hpa@zytor.com, randy.dunlap@oracle.com,
	wcohen@redhat.com, tglx@linutronix.de, jbaron@redhat.com,
	mhiramat@redhat.com, linux-tip-commits@vger.kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH][tip/perf/core] tracing: Rename TRACE_EVENT and others to something resonable
Date: Wed, 2 Dec 2009 21:16:38 +0100	[thread overview]
Message-ID: <20091202201635.GA5141@nowhere> (raw)
In-Reply-To: <1259784683.12870.100.camel@gandalf.stny.rr.com>

On Wed, Dec 02, 2009 at 03:11:23PM -0500, Steven Rostedt wrote:
> With the addition of TRACE_EVENT templates (or classes) the issue of
> naming has come up.
> 
> Originally, the template was called TRACE_EVENT_TEMPLATE. This was to be
> used to consolidate similar TRACE_EVENTs because a single TRACE_EVENT
> takes up quite a bit of code. One TRACE_EVENT creates a function to
> register and unregister a trace point, a function to record the event in
> a buffer, a function to display the binary output to user space, a
> function to add counters to record the number of times the event is
> reached, and so on.
> 
> All these functions creates a lot of bloat, especially since these
> functions are almost identical to each other. Unfortunately, these
> functions require specific parameters and structure fields, and can't
> always be the same. But for those events that share the same structure
> and parameters, a class/template allows them to share the same functions
> and this cuts down the bloat substantially.
> 
> But what to call these macros to satisfy the already confused kernel
> developers?
> 
> Ideally, DECLARE_EVENT_CLASS to create the class, DEFINE_EVENT to create
> an instance of the class, and even DEFINE_EVENT_CLASS to replace the
> current TRACE_EVENT that defines a class and creates an event of the
> same name as the class. New DEFINE_EVENTs may also reference a class
> declared by DEFINE_EVENT_CLASS.
> 
> But us kernel developers stay up too late at night, drinking jolt (or
> beer if you are in Europe), and our brain cells have fused to only
> logical circuitry, thus understanding concepts that are not engraved in
> stone becomes a bit too straining for us, and we may finally have to
> give up on solving this one last bug to get some rest with our love one
> that's been sleeping since 9pm.
> 
> This means using DECLARE_* and DEFINE_* will push us over that brink to
> normalcy and must be avoided. A new name must be established to clearly
> describe the mystical CPP magic that comprises the TRACE_EVENT hackery.
> Something that can bring us back to our roots. Something where it all
> begins. The stone age.
> 
> Thus, this patch renames the MACROS to the most obvious definitions
> around. Something we should have thought of at the start.
> 
> 
> s/DEFINE_EVENT_CLASS/FRED/g
> s/DEFINE_EVENT/WILMA/g
> s/TRACE_EVENT/BARNEY/g
> 
> 
> Thus with the new naming convention:
> 
> FRED(x, ...) -- will declare a class but will not make any events
> WILMA(x, y, ...) -- will create an event based off of class made by FRED
> BARNEY(x, ...) -- will create both a class and an event
> 
> /* Little known secret, WILMA can also fool around with BARNEY and can
> create new events with BARNEY as well as with FRED */
> 
>   (apologies to Thomas Gleixner and his renaming to "fred")
> 
> Signed-off-by: Steven Rostedt <flintstone@goodmis.org>


Acked-by: Frederic Weisbecker <fweisbec@gmail.com>


      reply	other threads:[~2009-12-02 20:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-01 17:18 [PATCH v2] tracing: add DEFINE_EVENT(), DEFINE_SINGLE_EVENT() support to docbook Jason Baron
2009-12-01 17:20 ` Randy Dunlap
2009-12-02 10:42 ` [tip:perf/core] tracing: Add " tip-bot for Jason Baron
2009-12-02 13:52   ` Steven Rostedt
2009-12-02 14:01     ` Ingo Molnar
2009-12-02 14:28       ` Steven Rostedt
2009-12-02 14:43         ` Ingo Molnar
2009-12-02 14:55           ` Steven Rostedt
2009-12-02 16:15             ` Randy Dunlap
2009-12-02 16:27             ` Mathieu Desnoyers
2009-12-02 17:11               ` Steven Rostedt
2009-12-02 18:06                 ` Mathieu Desnoyers
2009-12-02 18:19                   ` Steven Rostedt
2009-12-02 19:01                     ` trace/events: DECLARE vs DEFINE semantic Mathieu Desnoyers
2009-12-02 19:19                       ` Steven Rostedt
2009-12-02 19:34                         ` Randy Dunlap
2009-12-02 22:36                         ` Masami Hiramatsu
2009-12-02 22:46                           ` Steven Rostedt
2009-12-02 22:57                             ` Mathieu Desnoyers
2009-12-02 23:08                               ` H. Peter Anvin
2009-12-02 23:13                                 ` Steven Rostedt
2009-12-02 23:18                                   ` H. Peter Anvin
2009-12-02 23:15                                 ` Mathieu Desnoyers
2009-12-03  3:24                                   ` Masami Hiramatsu
2009-12-02 23:10                             ` Mathieu Desnoyers
2009-12-03  4:00                               ` Masami Hiramatsu
2009-12-03  4:07                                 ` Steven Rostedt
2009-12-03 13:51                                   ` Masami Hiramatsu
2009-12-03 13:54                                     ` Steven Rostedt
2009-12-03 14:09                                       ` Mathieu Desnoyers
2009-12-03 14:24                                         ` Steven Rostedt
2009-12-03 14:42                                           ` Mathieu Desnoyers
2009-12-03 15:31                                       ` Masami Hiramatsu
2009-12-03 15:56                                         ` Steven Rostedt
2009-12-03 16:11                                           ` Masami Hiramatsu
2009-12-02 20:11                       ` [PATCH][tip/perf/core] tracing: Rename TRACE_EVENT and others to something resonable Steven Rostedt
2009-12-02 20:16                         ` Frederic Weisbecker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091202201635.GA5141@nowhere \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=randy.dunlap@oracle.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=wcohen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.