Problem with CREATE_TRACE_POINTS and recursion safety

[Jeremy Fitzhardinge <jeremy@goop.org>]

I'm having a problem with CREATE_TRACE_POINTS being too indiscriminate.  
The trouble is that it not only creates tracepoint definitions for the 
intended tracepoints, but any other tracepoint definitions which get 
included incidentally.

For example, I'm seeing my paravirt tracepoints being instantiated in 
both kernel/sched.o and kernel/irq/manage.o as side-effects of the 
scheduler and irq tracepoints being instantiated.

I'm experimenting with a different scheme, wherein a subsystem defines 
CREATE_FOO_TRACE_POINTS in the .c file where it wants to instantiate the 
tracepoints - rather than CREATE_TRACE_POINTS - and its 
trace/events/foo.h does:

    #ifdef CREATE_FOO_TRACE_POINTS
    #undef CREATE_FOO_TRACE_POINTS	/* avoid infinite recursion */
    #include <trace/instantiate_trace.h>
    #else
    #include <trace/define_trace.h>
    #endif

where instantiate_trace.h is:

    #define CREATE_TRACE_POINTS
    #include <trace/define_trace.h>
    #undef CREATE_TRACE_POINTS

(Just to prevent a bit more repeated boilerplate in each events 
definition file.)

This seems to work.  (Update: no it doesn't.  WTF has paravirt-trace.o 
got duplicate kmem tracepoints?!)

A related problem is that the TRACE_INCLUDE_FILE mechanism doesn't work, 
because if any tracepoint definition header sets it, it overrides the 
setting for all others, so, for example, arch/x86/include/asm/paravirt.h 
ends up being included as the source of definitions for events/sched.h.  
I gave up and moved paravirt-trace.h to trace/events/pvops.h rather than 
try to deal with it.

Lucky for you Steven, none of this is getting any more pretty, so you 
may yet get your prize.

    J