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:	Sun, 17 Sep 2006 18:45:28 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	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

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

> > to both points i (and others) already replied in great detail - 
> > please follow up on them. (I can quote message-IDs if you cannot 
> > find them.)
> 
> What you basically tell me is (rephrased to make it more clear): 
> Implement kprobes support or fuck off! [...]

What i am saying (again and again) is: "the other option you suggest is 
not acceptable to me because a better solution exists" [for the many 
reasons outlined before]. Think about the STREAMS example: there too 
_that_ particular approach was rejected, because a better solution 
existed. (although it was a _much_ larger body of code that was 
rejected)

I'm not "forcing" kprobes on you: you can invent whatever other approach 
that solves the problems i and others raised, or you can have your own 
separate patchset - this is standard kernel acceptance procedure. 
Granted, kprobes is an existing solution with extensive existing 
infrastructure, so it's IMO the easiest solution technically, but you 
are certainly not 'forced' to do it. You want the feature on your 
architecture _without_ kprobes, solve the problems.

> [...] You make it very clear, that you're unwilling to support static 
> tracers even to point to make _any_ static trace support impossible. 
> It's impossible to discuss this with you, because you're absolutely 
> unwilling to make any concessions. [...]

Because we either accept the concept of static tracing or not - 
unfortunately there's no meaningful middle ground. I'd love it if there 
was some meaningful middle-ground, because then we'd not have this 
lengthy discussion at all. But sometimes such situations do happen. Same 
was true for STREAMS: the only choice was to either it was accepted or 
it was rejected. One cannot get a "little bit pregnant".

The "add some static markups" suggestion is IMO just tactical pretense: 
static tracing will only be fully functional once it grows a 
comprehensive set of static tracepoints, so once we accept a "little 
bit" of static tracing where all the tools are built around a full set 
of tracepoints, we've created an expectance to have all of it.

Hence my suggestion: forget static tracing for the LTT engine and 
concentrate on dynamic tracepoints with _static markups_. Do you realize 
that dynamic tracers can insert _function calls_ into static markups, 
today? [and i'm not talking about djprobes here but current existing 
SystemTap behavior.]

	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/