* Martin Bligh <[email protected]> wrote:
> an external patch is, indeed, pretty useless. Merging a few simple
> tracepoints should not be a problem [...]
the problem is, LTT is not about a 'few' tracepoints: it adds a whopping
350 tracepoints, a fair portion of it is multi-line with tons of
arguments.
$ diffstat patch-2.6.17-lttng-0.5.108-instrumentation*
98 files changed, 1450 insertions(+), 64 deletions(-)
saying "it's just a few lightweight tracepoints" misses two points: it's
not just a few, and it's not lightweight.
and the set of tracepoints never gets smaller. People who start to rely
on a tracepoint will scream bloody murder if it goes away or breaks.
Static tracepoints are a maintainance PITA that will rarely get smaller,
and will easily grow ...
> [...] - see blktrace and schedstats, for instance.
yes, i do want to remove the 34 schedstats tracepoints too, once a
feasible alternative is present. I already have to do two compilations
when changing something substantial in the scheduler - once with and
once without schedstats.
same for blktrace: once SystemTap can provide a compatible replacement,
it should.
> It amuses me that we're so opposed to external patches to the tree
> (for perfectly understandable reasons), but we somehow think
> tracepoints are magically different and should be maintained out of
> tree somehow.
i think you misunderstood what i meant. SystemTap should very much be
integrated into the kernel proper, but i dont think the _rules_ (and
scripts) should become part of the _source code files themselves_. So
yes, there's advantage to kernel integration, but there's disadvantage
to littering the kernel source with countless static tracepoints, if
dynamic tracepoints can offer the same benefits (or more).
the question is: what is more maintainance, hundreds of static
tracepoints (with long parameter lists) all around the (core) kernel, or
hundreds of detached dynamic rules that need an update every now and
then? [but of which most would still be usable even if some of them
"broke"] To me the answer is clear: having hundreds of tracepoints
_within_ the source code is higher cost. But please prove me wrong :-)
Ingo
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
