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 01:43:54 +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:

> > While with SystemTap the coupling is alot smaller.
> 
> What guarantees we don't have similiar problems with dynamic 
> tracepoints? As soon as any tracing is merged, users will have some 
> kind of expectation [...]

because users rely on the functionality, not on the implementation 
details. As i outlined it before: with dynamic tracers, static 
tracepoints _are not a necessity_. With static tracers, _static 
tracepoints are the only game in town_.

i outlined one such specific "removal of static tracepoint" example 
already: static trace points at the head/prologue of functions (half of 
the existing tracepoints are such). The sock_sendmsg() example i quoted 
before is such a case. Those trace points can be replaced with a simple 
GCC function attribute, which would cause a 5-byte (or whatever 
necessary) NOP to be inserted at the function prologue. The attribute 
would be alot less invasive than an explicit tracepoint (and thus easier 
to maintain):

 int __trace function(char arg1, char arg2)
 {
 }

where kprobes can be used to attach a lightweight tracepoint that does a 
call, not a break (INT3) instruction. With static tracers we couldnt do 
this so we'd have to stick with the static tracepoints forever! It's 
always hard to remove features, so we have to make sure we add the 
feature that we know is the best long-term solution.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ