linux-kernel - Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060914201448.GA7357@elte.hu>
Date:	Thu, 14 Sep 2006 22:14:48 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Martin Bligh <mbligh@...igh.org>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>, fche@...hat.com
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

* Martin Bligh <mbligh@...igh.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/