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: <20060917150035.GA20225@elte.hu>
Date:	Sun, 17 Sep 2006 17:00:35 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Roman Zippel <zippel@...ux-m68k.org>,
	Thomas Gleixner <tglx@...utronix.de>, karim@...rsys.com,
	Andrew Morton <akpm@...l.org>,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.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

* Frank Ch. Eigler <fche@...hat.com> wrote:

> [...]  It would be much better if we were able to sketch out plausible 
> designs for static instrumentation and similar dynamic probes, and 
> carry out gedanken experiments aobut how they would need to adopt to 
> realistic examples of code drift.  It is not the case that all 
> "maintenance" is alike.

see my previous mail - hopefully that explains my position even clearer.

A number of people have expressed doubts about the all-static model (i'm 
amongst them) - and that's all based on actual experience. So there's no 
need for Gedanken-experiments, because we've got real-life experiments
:-) A number of people also have expressed that they think an all-static
markup model is the right one - and that's based on experience as well.

Just looking at the opinions objectively and excluding my opinion i'd 
say that the most likely model will thus be a _hybrid_ one: some 
markups will be static, some will be dynamic.

Whether a tracepoint will be static or dynamic will depend on the 'flux 
of changes' in the tracing code and of the code they trace. If tracing 
code has a high flux, or the traced code has a high flux, then the 
lowest maintainance overhead is to have a dynamic tracepoint. If _both_ 
the tracing code and the traced code has low flux of changes, then the 
lowest maintainance overhead will be a static markup.

Put differently: dynamic markups will turn into static markups if the 
code that they handle "cools down". Static markups will turn into 
dynamic markups if the code where they reside in gets "too hot" or if 
the markups themselves are "too hot".

But one thing is sure: with a static tracer model accepted into the 
kernel we are forced to have a comprehensive, always-maintained, full 
set of static markups in the tree, for a long time. Dynamic tracers will 
still be around, but we wont be able to fully benefit from the more 
flexible tracepoint maintainance models they allow, because we'll always 
have to carry around the static markups, for the sake of static tracers. 
There will likely be periodic friction about how many static markups 
there should be in the source: subsystem maintainers will want them out, 
static-trace-users will want them in. If a crutial static markup is 
removed or damaged then the kernel will regress materially.

	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/