public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: mathieu.desnoyers@polymtl.ca, Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH 2/4] x86/pvops: target CREATE_TRACE_POINTS to particular subsystems
Date: Fri, 17 Apr 2009 10:14:47 -0700	[thread overview]
Message-ID: <49E8B907.9000109@goop.org> (raw)
In-Reply-To: <alpine.DEB.2.00.0904171251490.14919@gandalf.stny.rr.com>

Steven Rostedt wrote:
> On Fri, 17 Apr 2009, Jeremy Fitzhardinge wrote:
>
>   
>> Steven Rostedt wrote:
>>     
>>> Ah yes! It needs to be:
>>>
>>> #ifdef CONFIG_IRQ_TRACE_POINTS
>>> #undef CONFIG_IRQ_TRACE_POINTS
>>> #include <trace/define_trace.h>
>>> #endif
>>>
>>> Otherwise we get into the recursion again.
>>>   
>>>       
>> We should probably also move the #define TRACE_SYS in there as well (without
>> the #undef), as it should only have one definition at a time...
>>     
>
> Actually, I'm kind of against that. Just because as it stands, the 
> TRACE_SYSTEM macro is up at the top, and it is easy to see.
>   

Yes, but it means that if you're in the middle of 
CREATE_FOO_TRACE_POINTS and foo.h happens to include bar.h, suddenly 
TRACE_SUBSYSTEM becomes bar...

> Actually, we could do (from the top of the file)
>
> #ifdef CONFIG_IRQ_TRACE_POINTS
> #undef CONFIG_IRQ_TRACE_POINTS
>
> #define TRACE_SYSTEM irq
>
> #include <trace/define_trace.h>
>
> #elif !defined(_TRACE_IRQ_H) || defined(TRACE_HEADER_MULTI_READ)
> #define _TRACE_IRQ_H
>
> #include <linux/tracepoint.h>
> #include <linux/interrupt.h>
>
>
> [...]
>
> #endif
>   

That's slightly different from what we have now.  At the moment its

    #if !defined(_TRACE_IRQ_H)...
    ...
    #endif

    #ifdef CREATE_IRQ_TRACE_POINTS
    ...
    #endif

So we get both the main part of the file and the CREATE_X_TRACE_POINTS 
parts.  Your suggestion makes them exclusive:

    #ifdef CREATE_IRQ_TRACE_POINTS
    ...
    #elif !defined(_TRACE_IRQ_H)...
    ...
    #endif
      

Does that make a difference?

    J

  reply	other threads:[~2009-04-17 17:14 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17  6:35 [PATCH] tracing WIP patches Jeremy Fitzhardinge
2009-04-17  6:35 ` [PATCH 1/4] tracing: move __DO_TRACE out of line Jeremy Fitzhardinge
2009-04-17 15:46   ` Ingo Molnar
2009-04-17 16:10     ` Mathieu Desnoyers
2009-04-17 16:23       ` Ingo Molnar
2009-04-17 16:47         ` Jeremy Fitzhardinge
2009-04-17 19:31         ` Jeremy Fitzhardinge
2009-04-17 19:46           ` Ingo Molnar
2009-04-17 19:57             ` Steven Rostedt
2009-04-17 19:58             ` Jeremy Fitzhardinge
2009-04-17 20:06               ` Steven Rostedt
2009-04-18  6:53           ` Mathieu Desnoyers
2009-04-18 14:16             ` Steven Rostedt
2009-04-19  3:59               ` Mathieu Desnoyers
2009-04-19 23:38                 ` Jeremy Fitzhardinge
2009-04-20 21:39                   ` Mathieu Desnoyers
2009-04-19 23:40             ` Jeremy Fitzhardinge
2009-04-20 21:47               ` Mathieu Desnoyers
2009-04-17  6:35 ` [PATCH 2/4] x86/pvops: target CREATE_TRACE_POINTS to particular subsystems Jeremy Fitzhardinge
2009-04-17 15:55   ` Steven Rostedt
2009-04-17 16:14     ` Jeremy Fitzhardinge
2009-04-17 16:32       ` Steven Rostedt
2009-04-17 16:48         ` Jeremy Fitzhardinge
2009-04-17 16:57           ` Steven Rostedt
2009-04-17 17:14             ` Jeremy Fitzhardinge [this message]
2009-04-17 17:33               ` Steven Rostedt
2009-04-17 18:11                 ` Jeremy Fitzhardinge
2009-04-17  6:35 ` [PATCH 3/4] tracing: pass proto and args to DEFINE_TRACE Jeremy Fitzhardinge
2009-04-17  6:48   ` Christoph Hellwig
2009-04-17  6:58     ` Jeremy Fitzhardinge
2009-04-17  7:05       ` Christoph Hellwig
2009-04-17 12:53         ` Ingo Molnar
2009-04-17 15:21     ` Mathieu Desnoyers
2009-04-17  6:35 ` [PATCH 4/4] tracing: avoid warnings from zero-arg tracepoints Jeremy Fitzhardinge
2009-04-17 15:53   ` Steven Rostedt
2009-04-17 15:53   ` Ingo Molnar
2009-04-17 16:10   ` [tip:tracing/core] " tip-bot for Jeremy Fitzhardinge

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=49E8B907.9000109@goop.org \
    --to=jeremy@goop.org \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox