Re: [GIT PULL] Performance Counters for Linux

[Linus Torvalds <torvalds@linux-foundation.org>]

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