Re: Problem with CREATE_TRACE_POINTS and recursion safety

[Jeremy Fitzhardinge]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/