All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mathieu Desnoyers <compudj@krystal.dyndns.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Li Zefan <lizf@cn.fujitsu.com>, Christoph Hellwig <hch@lst.de>,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [PATCH 2/2][RFC] tracing: Add extract out softirq names used by irq trace events
Date: Sat, 27 Feb 2010 11:39:39 +0100	[thread overview]
Message-ID: <20100227103937.GF5130@nowhere> (raw)
In-Reply-To: <1267151179.6328.86.camel@gandalf.stny.rr.com>

On Thu, Feb 25, 2010 at 09:26:19PM -0500, Steven Rostedt wrote:
> On Fri, 2010-02-26 at 00:48 +0100, Frederic Weisbecker wrote:
> 
> > 
> > And what about a kind of macro that could have two effects:
> > 
> > - define the enum
> > - define the nr -> name pairs for resolution
> > 
> > This could be something like:
> > 
> > define_trace_enum(softirq)
> > 	enum_entry(TASKLET, 4), //don't know if it's 4, just an example
> > 	enum_entry(HRTIMER, 5),
> > end_trace_enum()
> 
> That wont work. Unless it is in a separate file that can be included
> over and over again. That is we would need:
> 
> ** include/linux/softirq_names.h:
> 
> define_trace_enum(softirq)
> 	enum_entry(HI, 0),
> 	enum_entry(TIMER, 1),
> 	[...]
> end_trace_enum();
> 
> 
> 
> ** include/trace/define_enum.h:
> 
> #define define_trace_enum(name)  enum name {
> #define enum_entry(a, b)  a = b
> #define end_trace_enum()  }
> 
> 
> ** include/linux/interrupt.h
> 
> /* instead of declaring an enum we have */
> 
> #include <trace/define_enum.h>
> #include <linux/softirq_names.h>
> 
> Here we could do something special with that file.



Right.



> 
> > 
> > (My naming sucks, as usual).
> > 
> > In normal headers, it would define an enum:
> > 
> > enum softirq {
> > 	TASKLET = 4,
> > 	HRTIMER = 5,
> > };
> > 
> > And in the file that has DEFINE_TRACEPOINT:
> > 
> > /* can be in ftrace_event.h */
> > struct resolve_enum {
> > 	const char *name;
> > 	int val;
> > };
> > 
> > struct resolve_enum softirq = { //come from define_trace_enum()
> > 	{"TASKLET", 4}, //come from enum_entry()
> > 	{"HRTIMER", 5},
> > 	{ NULL, 0}, /* end */
> > };
> > 
> > /* This can be used from the trace_event macro */
> > const char *softirq_name(int nr)
> > {
> > 	return resolve_enum[nr];
> > }
> > 
> > 
> > And then you can get back the struct resolve_enum softirq
> > to export the values to debugfs, may be by storing such
> > structures in a section (and adding the name of the enum)
> > 
> > This has the advantage of beeing sync with core header
> > changes, but this has the drawback of beeing less readable
> > to define an enum usable from a TRACE_EVENT (especially
> > if I define the naming personally).
> > 
> 
> 
> This just gets ugly and I'm not sure people would like doing this. It
> also requires that you number the enums specifically.


Yeah :-(



> 
> A better way could be this:
> 
> ** include/linux/interrupt.h
> 
> #define SOFTIRQ_NAMES 	\
> 	C(HI),		\
> 	C(TIMER),	\
> 	[...]		\
> 	C(RCU)
> 
> #define C(name)		name##_SOFTIRQ
> 
> enum { SOFTIRQ_NAMES, NR_SOFTIRQS };
> 
> #undef C
> 
> And in the trace file we could do:
> 
> #define C(name)  { #name, name##_SOFTIRQ, sizeof(name##_SOFTIRQ) }
> 
> struct {
> 	char *name;
> 	int val;
> 	int size;
> } softirq_names[] __attribute__((section("trace_syms"))) =
>   { SOFTIRQ_NAMES };
> 
> #undef C
> 
> 
> This way we don't need to number every enum, or have to move the enum
> into another file. My question is...
> 
> Would the following be acceptable in normal headers?
> 
> #define ENUM_NAMES  	\
> 	C(a),		\
> 	C(b),		\
> 	...
> 
> #define C(name) name
> 
> enum { ENUM_NAMES };
> 
> #undef C



Could be acceptable, this should only concern rare enums I
guess.



> -- Steve
> 
> 


      reply	other threads:[~2010-02-27 10:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-12 19:09 [PATCH 0/2][RFC] tracing: Showing symbols for TRACE_EVENT Steven Rostedt
2010-02-12 19:09 ` [PATCH 1/2][RFC] tracing: Add EXTRACT_TRACE_SYMBOL() macro Steven Rostedt
2010-02-12 19:09 ` [PATCH 2/2][RFC] tracing: Add extract out softirq names used by irq trace events Steven Rostedt
2010-02-13 10:39   ` Peter Zijlstra
2010-02-13 11:11     ` Steven Rostedt
2010-02-25 23:48       ` Frederic Weisbecker
2010-02-26  2:26         ` Steven Rostedt
2010-02-27 10:39           ` 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=20100227103937.GF5130@nowhere \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=compudj@krystal.dyndns.org \
    --cc=fengguang.wu@intel.com \
    --cc=hch@lst.de \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.