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:	Sat, 16 Sep 2006 10:20:54 +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:

> > this tracepoint, under a dynamic tracing concept, can be replaced with:
> > 
> >  int __trace sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
>
> A nice example where you make life more difficult for static tracers 
> for no reason, [...]

No, it's simply a clever feature: "halve the impact of static markups".

What you say will be _precisely_ the kind of situations that make me 
very wary of static tracers. Someone does something smart that enables 
us to remove half of the tracepoints from the kernel source code, while 
you will go on and complain: "why do you make the life harder for static 
tracers". You, perhaps inwillingly, are giving the perfect demonstration 
of why static tracepoints are a maintainance problem: once added _they 
can not be removed without breaking static tracers_.

And i see you didnt reply to (and you didnt even quote) the paragraph 
that i believe answers your point:

> > the user of course does not care about kernel internal design and 
> > maintainance issues. Think about the many reasons why STREAMS was 
> > rejected - users wanted that too. And note that users dont want 
> > "static tracers" or any design detail of LTT in particular: what 
> > they want is the _functionality_ of LTT.

The kernel tree is not there to make it easier for inferior approaches. 
How hard is it for the static tracer folks to take a look at dynamic 
tracers and realize that it's the fundamentally better approach, for the 
reasons above and for other reasons, and pick the concept up and 
integrate it with their code? Just like the STREAMS folks had a chance 
to look at the existing TCP/IP implementation in the Linux kernel and 
had the chance to realize that it's the better approach. Yet they 
insisted on just adding a few hooks here and there, to "make the life 
easier for STREAMS".

	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/