Messages in this thread | | | Date | Thu, 14 Sep 2006 22:14:48 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 |
| |
* Martin Bligh <mbligh@mbligh.org> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |