All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <srostedt@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Christoph Hellwig <hch@lst.de>, Arnd Bergmann <arnd@arndb.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	cbe-oss-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	Fr?d?ric Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH, RFC] sputrace: use the generic event tracer
Date: Wed, 06 May 2009 10:59:28 -0400	[thread overview]
Message-ID: <1241621968.11379.23.camel@localhost.localdomain> (raw)
In-Reply-To: <20090506144708.GC29044@elte.hu>


On Wed, 2009-05-06 at 16:47 +0200, Ingo Molnar wrote:
> * Steven Rostedt <srostedt@redhat.com> wrote:
> 
> > 
> > On Wed, 2009-05-06 at 13:23 +0200, Ingo Molnar wrote:
> > 
> > > > > > +# magic for the trace events
> > > > > > +CFLAGS_sched.o := -I$(src)
> > > > > 
> > > > > Steve, i'm wondering whether this type of Makefile hackery (caused 
> > > > > by modular tracepoints) could be eliminated ...
> > > > 
> > > > We would just have to include the header file with "" instead of 
> > > > <>. But I remember Steve not liking this when we talked about it.
> > > 
> > > Yeah. But changing Makefiles isnt particularly clean either ...
> > > 
> > > And adding -I$(src) can have side-effects: we often have a local 
> > > foo.h while an include/linux/foo.h as well.
> > 
> > That still would not conflict, because
> > 
> > #include "foo.h"
> > 
> > will not include "linux/foo.h" and
> > 
> > #include <linux/foo.h>
> > 
> > will not include a local foo.h, unless there's also a local "linux"
> > directory with a foo.h in it.
> >
> > The Makefile hack has to do with being able to have the "foo.h" 
> > file with the TRACE_EVENTs someplace other than include/trace.
> > 
> > If the "foo.h" is in include/trace.h we do not need to include 
> > this hack. But because the include/trace/define_trace.h needs to 
> > include the "foo.h" file recursively, it must be able to find it. 
> > If we do not add a search path, include/trace/define_trace.h will 
> > not look in the other locations.
> > 
> > Note, as Christoph did, we only need to add the include path to 
> > the file that defines "CREATE_TRACE_POINTS". Which is only one 
> > file.
> > 
> > CFLAGS_sched.o := -I$(src)
> > 
> > Only touches the sched.c file in that directory (Note, for those 
> > reading this thread out of context, this is not the same file as 
> > kernel/sched.c)
> 
> Yeah, i guess we can live with it. It still feels imperfect though.

Yeah, I dislike it too. But this is a limitation on CPP. When we get
sparse to replace CPP then we can fix it there ;-)

> 
> (btw., find below a small typo fix)
> 
> 	Ingo
> 
> diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
> index f7a7ae1..1d6fa17 100644
> --- a/include/trace/define_trace.h
> +++ b/include/trace/define_trace.h
> @@ -1,5 +1,5 @@
>  /*
> - * Trace files that want to automate creationg of all tracepoints defined
> + * Trace files that want to automate the creation of all tracepoints defined
>   * in their file should include this file. The following are macros that the
>   * trace file may define:
>   *

Thanks,

-- Steve



  reply	other threads:[~2009-05-06 15:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090506102918.GA23278@lst.de>
2009-05-06 10:57 ` [PATCH, RFC] sputrace: use the generic event tracer Ingo Molnar
2009-05-06 11:02   ` Christoph Hellwig
2009-05-06 11:23     ` Ingo Molnar
2009-05-06 13:54       ` Steven Rostedt
2009-05-06 14:47         ` Ingo Molnar
2009-05-06 14:59           ` Steven Rostedt [this message]
2009-05-06 16:53   ` Frederic Weisbecker
2009-05-06 17:13     ` Christoph Hellwig
2009-05-06 19:05       ` Steven Rostedt
2009-05-10 19:07         ` [Cbe-oss-dev] " Christoph Hellwig
2009-05-06 10:58 ` Ingo Molnar

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=1241621968.11379.23.camel@localhost.localdomain \
    --to=srostedt@redhat.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=fweisbec@gmail.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.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 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.