From: Ingo Molnar <email@example.com>
To: Steven Rostedt <firstname.lastname@example.org>
Cc: LKML <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
Frederic Weisbecker <email@example.com>
Subject: Re: [PATCH][GIT PULL][v3.3] tracing: Add header wrappers event_headers_start.h and event_headers_end.h
Date: Tue, 17 Jan 2012 10:54:18 +0100 [thread overview]
Message-ID: <20120117095418.GG10397@elte.hu> (raw)
* Steven Rostedt <firstname.lastname@example.org> wrote:
> This is actually a special pull request. This patch adds two new files
> that are not used by anyone. The rational for this is, they will be
> required for v3.4 and I want to make the transition in linux-next as
> smooth as possible. Let me explain the situation.
> There has been more and more cases where trace/events/*.h headers have
> been showing up in normal header files. This is fine unless one of these
> normal header files ends up included in another trace/events/*.h file.
> What happens then, is when the CREATE_TRACE_POINTS is defined both
> headers get evaluated. This means the C functions to create the
> tracepoints are created for both the initial trace/events/*.h header, as
> well as the one that got included by the normal header file. This makes
> the build fail. We've already had to fix this up a few times to handle
> these cases.
> I added two header files:
> These headers add some macro magic to handle the nested tracepoint event
> headers that was described above.
> The way this works is that all tracepoint event headers must include
> these two headers around their other includes. For example trace/sched.h
> will now have:
> #include <trace/event_headers_start.h>
> #include <linux/sched.h>
> #include <linux/tracepoint.h>
> #include <trace/event_headers_end.h>
> I've already updated all the tracepoint headers inside the latest
> kernel. I searched all headers with "TRACE_EVENT" in them to catch
> headers outside of trace/events/ that define trace event headers.
> The issue I see, and why I want this patch into 3.3 is that I have a
> warning that will print if someone adds a new tracepoint event header
> and doesn't add these files. If this warning goes into linux-next, and
> someone adds a new tracepoint event header, they will start getting this
> warning. The only way for them to stop it, is to include the above
> wrappers. The problem is, the wrappers will not exist in the kernel that
> gets pulled into linux-next, unless we push them now into 3.3.
> Now if you feel this is too much and do not want to include files into
> 3.3 that are not being used, I can hold off the warning patch until 3.5,
> and then we may have a mixture of files with and without these header
> wrappers in 3.4.
> What's your thoughts on this?
Hm, i don't really like the extra complexity - this code
*really* does not need any more complexity ...
How about the low-tech solution of adding some text between
'/* */' markers to warns that these headers should not be
included in ordinary headers?
The build error will pinpoint the bug anyway, it's not like the
kernel can be broken in any dangerous way.
next prev parent reply other threads:[~2012-01-17 9:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-16 22:57 [PATCH][GIT PULL][v3.3] tracing: Add header wrappers event_headers_start.h and event_headers_end.h Steven Rostedt
2012-01-17 9:54 ` Ingo Molnar [this message]
2012-01-17 13:32 ` Steven Rostedt
2012-01-18 12:07 ` Ingo Molnar
2012-01-18 17:56 ` Steven Rostedt
2012-01-22 22:59 ` Rusty Russell
2012-01-26 2:41 ` [RFC][PATCH] tracing/module: Move tracepoint out of module.h Steven Rostedt
2012-01-26 2:45 ` Steven Rostedt
2012-01-26 10:28 ` Ingo Molnar
2012-01-26 13:52 ` Steven Rostedt
2012-01-26 13:55 ` Ingo Molnar
2012-01-26 14:04 ` Steven Rostedt
2012-01-26 14:07 ` Steven Rostedt
2012-01-26 14:36 ` Steven Rostedt
2012-01-26 18:39 ` Ingo Molnar
2012-01-27 3:02 ` Rusty Russell
2012-01-30 11:52 ` Steven Rostedt
2012-01-30 17:28 ` Steven Rostedt
2012-01-31 3:58 ` Rusty Russell
2012-01-31 12:20 ` Ingo Molnar
2012-01-31 12:50 ` Steven Rostedt
2012-02-01 6:48 ` Rusty Russell
2012-02-01 13:27 ` Steven Rostedt
2012-02-01 13:49 ` Ingo Molnar
2012-02-01 14:25 ` Steven Rostedt
2012-03-29 4:22 ` Eric Dumazet
2012-03-29 5:24 ` Rusty Russell
2012-02-01 1:10 ` Rusty Russell
2012-02-01 7:09 ` Ingo Molnar
2012-01-30 6:40 ` Li Zefan
2012-02-17 13:46 ` [tip:perf/core] tracing/softirq: Move __raise_softirq_irqoff() out of header tip-bot for Steven Rostedt
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).