2008/10/23 Ingo Molnar <mingo@xxxxxxx>: > to answer the "is that a lockdep or just trace feature" question: > > trace-irqflags was first written by me for the (crude) ftrace-precursor > latency tracer code in -rt, years ago. Then i reused it (and changed it > alot) for upstream lockdep, two years ago. Then ftrace came in this year > and reused it. > > so it's rather symbiotic ;-) > > So ... the tracers that rely on irqflags-tracing should definitely be > limited to architectures that provide TRACE_IRQFLAGS. The core trace.c > itself should probably not be restricted ... (and it should definitely > build) > > Ingo > Ok, so perhaps it needs a kind of disambiguation between CONFIG_TRACE_IRQFLAGS and CONFIG_TRACE_IRQFLAGS_SUPPORT :) So, if those arch may not support irqflags, I should forget about including linux/irqflags.h But to let the core trace.c to be built for other types of tracing, the best thing I see is to put some ifdef CONFIG_TRACE_IRQFLAGS on the tracing_cpumask functions and structure, and actually on the creation of this file. No bad feelings about this solution? -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
