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: <450B0585.5070700@opersys.com>
Date:	Fri, 15 Sep 2006 15:56:53 -0400
From:	Karim Yaghmour <karim@...rsys.com>
To:	tglx@...utronix.de
CC:	Andrew Morton <akpm@...l.org>, Paul Mundt <lethal@...ux-sh.org>,
	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>,
	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


Thomas Gleixner wrote:
> One thing which is much more important IMHO is the availablity of
> _USEFUL_ postprocessing tools to give users a real value of
> instrumentation. This is a much more complex task than this whole kernel
> instrumentation business. This also includes the ability to coordinate
> user space _and_ kernel space instrumentation, which is necessary to
> analyse complex kernel / application code interactions. 

And of course the usefulness of such postprocessing tools is gated
by the ability of users to use them on _any_ kernel they get their
hands on. Up to this point, this has not been for *any* of the
existing toolsets, simply because they require the user to either
recompile his kernel or modify his probe points to match his kernel.
Until users can actually do without either of these steps (which is
only possible with static markup) then the development teams of
the various projects will continue having to invest resources
chasing the kernel.

We don't need separate popstprocessing tool teams. The only reasons
there are separate project teams is because managers in key
positions made the decision that they'd rather break from existing
projects which had had little success mainlining and instead use
their corporate bodyweight to pressure/seduce kernel developers
working for them into pushing their new great which-aboslutely-
has-nothing-to-do-with-this-ltt-crap-(no,no, we actually agree
with you kernel developers that this is crap, this is why we're
developing this new amazing thing). That's the truth plain and
simple.

When I started involving myself in Linux development a decade ago,
I honestly did not think I'd ever see this kind of stuff happen,
but, hey, that's life.

Karim

-
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