Re: [PATCH 0/18] Allow different tracers to be compiledindependently

[Frederic Weisbecker]

On Tue, Mar 23, 2010 at 01:32:02AM +0100, Jan Kara wrote:
> 
>   Hi,
> 
>   currently, when one tracer is selected, most of tracepoints for other
> tracers also gets pulled into the kernel. So for example it's not possible
> to enable BLK_DEV_IO_TRACE without polluting slab allocation paths with
> tracepoint checks (see changelog of patch 01). This patch set adds a
> possibility for each set of trace points to be compile-enabled separately.
>   The first patch contains the necessary magic in linux/tracepoint.h. Other
> patches just tell tracing framework about correspoding config options
> and possibly introduce them if they did not exist before.
>   The patches in this patch set are actually completely independent so 
> they can be merged via respective subsystem trees. But changes are rather
> tiny so I don't expect much conflicts...
> 
> 								Honza


(Adding more people in Cc)

I don't know. Yeah this first looks like a good idea but once
CONFIG_EVENT_TRACING is enabled, each tracepoint is a lightweight
thing and induce a tiny overhead, probably hard to notice, and
this is going to be even more the case after the jmp label
optimization patches.

I liked the fact we had a general tracing kernel once the above
config is selected. And we don't bother telling people that to
use tool X you need CONFIG_EVENT_Y, and you need to rebuild your
kernel, etc...

I wonder if this is going to be a win.

--
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/