[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49E69CED.9050706@goop.org>
Date: Wed, 15 Apr 2009 19:50:21 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC: Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Problem with CREATE_TRACE_POINTS and recursion safety
Mathieu Desnoyers wrote:
> Jeremy brings up an interesting point. Given that we might eventually
> include a few tracepoint header files in a given C file, but with the
> intent of only "creating" the tracepoint callbacks for few of these, the
> global "CREATE_TRACE_POINTS" flag makes little sense and seems like it
> will easily lead to link-time errors.
>
Yes, that's what I'm seeing.
> Maybe we could consider requiring something like the following solution :
>
> In the .c file :
>
> #define CREATE_TRACE_POINTS
> #include <trace/subsysa.h>
> #undef CREATE_TRACE_POINTS
>
> #include <trace/subsysb.h>
>
> Where subsysa has its trace points callbacks created, but subsysb
> doesn't. This seems half-way understandable, at least.
But what if trace/subsysa.h includes some other headers to define some
types it needs, which in turn ends up incidentally including
trace/subsysc.h (either directly, or indirectly via any number of other
headers? Then it will end up instantiating tracepoints for subsysa and
subsysc. The only way to avoid it would be to impose an absolutely
strict separation of type/constant definition headers from
function/tracepoint ones.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists