Re: Problem with CREATE_TRACE_POINTS and recursion safety

[Steven Rostedt]

On Wed, 15 Apr 2009, Jeremy Fitzhardinge wrote:

> 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.

I hate to do this because it adds some more work to the developer adding a 
new trace point header, but we could just remove the CREATE_TRACE_POINTS 
and do in the trace/events/*.h headers:

#ifdef CREATE_FOO_TRACE_POINTS
#include <trace/define_trace.h>
#endif

in all tracepoint headers. I originally had it this way with just the 
CREATE_TRACE_POINTS, but Christoph Hellwig and Mathieu both suggested 
putting that into define_trace.h.  It seems so much cleaner to keep it in 
define_trace.h, but if it is causing too many headaches, it may not be 
worth it :-/

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/