On Thu, 27 Feb 2014 02:21:16 +0000 (UTC) Mathieu Desnoyers <[email protected]> wrote:
> That is not the question. We don't care about how many times module.h is > included in the kernel, but rather what module.h itself includes and could > include in the future, throughout generic and arch-specific headers. If > someone want to add a tracepoint in a static inline function located within > a header file, they will need to include tracepoint.h. If tracepoint.h > happens to have a circular dependency on this header, there comes include > hell. Actually, we've been telling people not to do that. That is, we don't allow for tracepoints to be in headers anymore. We've removed all of the offenders. > > Arguing that it's OK to include headers within core instrumentation code > because they are themselves included pretty much everywhere is a paved way > to said include hell IMHO. I find tracepoint.h far from a core instrumentation code. It's for static tracepoints only. It's not like rcu or spinlock. It's about as core as module.h is. I would argue that module.h is an even more core header than tracepoint.h. > > > > But as a compromise, I can move it to ftrace_event.h instead. > > Since it will be used in tracepoint.c as well, which is a foundation of > ftrace_event, it would be bad coupling to make tracepoint.c include > ftrace_event.h (abstraction inversion). So I still think tracepoint.h > is the right place to put this, only not with the module.h dependency. > > But perhaps I'm missing something. Why is it so important to you to make > this a static inline rather than a regular function call ? As it is a one liner check, it just seemed to fit as a static inline. As this isn't in any fast path, I guess I could make it a normal function call. Fine, I'll do that instead. Then the module header change can go into linux-next instead of mainline/stable. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
