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 23:28:36 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Karim Yaghmour <karim@...rsys.com>
Cc:	Jes Sorensen <jes@....com>, Roman Zippel <zippel@...ux-m68k.org>,
	Ingo Molnar <mingo@...e.hu>,
	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

On Fri, Sep 15, 2006 at 10:31:51AM -0400, Karim Yaghmour wrote:
> Jes Sorensen wrote:
> > Because other people have tried to use LTT for additional projects,
> > but said projects haven't been integrated into LTT. In other words,
> > just because *you* haven't added those, doesn't mean someone else
> > won't try and do it later, if LTT was integrated.
> 
> Thank you. I will take it as a complement and likely laminate this
> email for your suggestion that I've acted responsibly in my
> maintenance of ltt. Boy, can you imagine what this debate would
> have looked like if I had included precisely those additional
> projects ...
> 
Which brings back the point of static tracepoints being entirely
subjective. By this line of reasoning, you define for other people what
the useful tracepoints are, and couldn't care less which points they're
actually interested in. How exactly is this serving the need of people
looking for instrumentation, rather than a pre-canned view of what they
can trace? If they already have to go with their own tracepoints for the
things they're interested in, then having a few static points
pre-existing doesn't really buy anyone much else either, especially if
by your own admission you're not integrating the points that people
_are_ interested in.

I'm not indicating that you didn't do exactly what you should have in
this situation, only that static tracepoints in general are only going
to be a small part of the picture, and not a complete solution to most
people on their own. Dynamic instrumentation fills the same sort of gap
without worrying about arbitrary maintenance, so what exactly does
shoving static instrumentation in to the kernel buy us?
-
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