Re: [GIT PULL] Performance Counters for Linux

From: Linus Torvalds
Date: Thu Jun 11 2009 - 14:35:38 EST

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at