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]

Date:	Fri, 15 Sep 2006 00:15:21 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Daniel Walker <dwalker@...sta.com>,
	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>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

* Roman Zippel <zippel@...ux-m68k.org> wrote:

> Hi,
> 
> On Thu, 14 Sep 2006, Daniel Walker wrote:
> 
> > > Ingo, so far you have made not a single argument why they can't coexist 
> > > except for your personal dislike.
> > 
> > Not to put to fine a point on it, but I think there's not a small number
> > of us that "prefer" the best solution.
> 
> You can have it.
> OTOH I would also like to know what's going in my m68k kernel without 
> having to implement some rather complex infrastructure, which I don't 
> need otherwise. There hasn't been a single argument so far, why we 
> can't have both.

the argument is very simple: LTT creates strong coupling, it is almost a 
set of 350+ system-calls, moved into the heart of the kernel. Once moved 
in, it's very hard to remove it. "Why did you remove that trace 
information, you broke my LTT script!"

While with SystemTap the coupling is alot smaller. With dynamic tracing 
there's no _fundamental requirement_ for _any_ tracepoint to be in the 
source code, hence we have the present and future flexibility to 
eliminate most of them. So my point is: shape all the static tracepoints 
in a "provide data to dynamic tracers" way. If they are removed (which 
we should have the freedom to do), the removal is not a showstopper.

Flexibility of future choices, especially for user/developer-visible 
features, is one of the most important factors of kernel maintainance.

	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/