Re: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint code

[Steven Rostedt]

On Thu, 27 Feb 2014 02:21:16 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/