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]

Date:	Thu, 11 Jun 2009 11:34:01 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Martin Bligh <mbligh@...gle.com>
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

On Thu, 11 Jun 2009, Martin Bligh wrote:
> 
> We actually ended up coming to the same conclusion as you for some of the
> internal tools we use that are tightly tied to the kernel. There is one hitch,
> which is that if you boot between different kernel versions, you need multiple
> userspace versions of the tools, so you may need to put them in
> /lib/modules/<kernel-version> or something equivalent, not one fixed place.

So I actually think this is broken.

No tool should ever be _that_ tightly tied to a kernel. If they are, they 
are broken, plain and simple.

A stable user-space ABI is still a requirement.

What the "keep it in the kernel sources" approach hopefully allows is

 - taking advantage of new features in a timely manner.

   NOT with some ABI breakage, but simply things like supporting a new CPU 
   architecture or new counters. The thing that oprofile failed at so 
   badly in my experience. 

 - Make it easier for developers, and _avoiding_ the horrible situation 
   where you have two different groups that don't talk well to each other 
   because one is a group of user-space weenies, and the other is a group 
   of manly kernel people, and there is no common ground.

And no, I'm not going to "guarantee" that this works well. Again, I just 
know that the separation didn't work. Let's just _try_ to do it this way, 
and see how it works.

But at no point will it be acceptable to have kernel version dependencies. 
Install the newest version of the binaries, and it should support older 
kernels too (within reason). 

The "within reason" is because (a) it's new, so early on you might see 
breakage, and (b) because we do tend to allow system tools to break 
occasionally. Not nearly often enough to make it valid to design around 
it, though.

		Linus
--
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/