linux-kernel - Re: [GIT PULL] Performance Counters for Linux

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: <20090612040751.GA20922@bombadil.infradead.org>
Date:	Fri, 12 Jun 2009 00:07:51 -0400
From:	Kyle McMartin <kyle@...artin.ca>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Al Viro <viro@...IV.linux.org.uk>, Ingo Molnar <mingo@...e.hu>,
	"David S. Miller" <davem@...emloft.net>,
	Stephane Eranian <eranian@...glemail.com>,
	linux-kernel@...r.kernel.org, Paul Mackerras <paulus@...ba.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] Performance Counters for Linux

[With my Fedora on.]

On Thu, Jun 11, 2009 at 10:06:55AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 11 Jun 2009, Christoph Hellwig wrote:
> > 
> > So what point is there in keeping it in-tree except making life hell for
> > packagers?
> 
> Give it up. Packagers can trivially generate their own sub-packages. They 
> do it all the time. They already do it for the user-mode header files, 
> extracted from the kernel - something you've worked on yourself.
> 
> So your point is clearly bogus, and dishonest.
> 
> You haven't actually looked the real problem in the eye, and acknowledged 
> the disaster that is oprofile. Let's give a _new_ approach a chance, and 
> see if we can avoid the mistakes of yesteryear this time.
> 

This is actually somewhat complicated for (at least, I can only speak
from experience for...) Fedora and Debian/Ubuntu. Having this in-kernel
means any bugfixes needed for the 'perf' tool, require patching the
kernel source, which will result in a whole new kernel rpm being built.
So in order to update their 'perf' tool, users will get a new kernel,
debuginfo, etc., with it.

So either we need to split it out into its own source tarball, or ship
the kernel source again in a seperate source package. I know which I'm
going to tend to favour...

Obviously, I understand the reasons for doing this, but I don't really
see it as a sensible long term option for a mature tool. But,
whatever, it's not my call. We'll just work around whatever happens.

regards, Kyle
--
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/