Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

From: Ingo Molnar
Date: Mon Feb 11 2013 - 12:41:21 EST

* David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:

> On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
> > To use another, perhaps more applicable analogy:
> >
> > If one has the choice to start a new business in the U.S., it
> > would be reasonable to do that. There's a lot of supporting
> > infrastructure, trust, distribution, standards, enforcement
> > agencies and available workers.
> >
> > Could the same business succeed in Somalia as well? Possibly -
> > if it's a bakery or something similarly fundamental. More
> > complex businesses would likely not thrive very well there.
> >
> > *That* is how I think the current Linux kernel tooling landscape
> > looks like currently in a fair number of places: in many aspects
> > it's similar to Somalia - disjunct entities with not much
> > commonality or shared infrastructure.
> That's complete nonsense. If you want to use pieces of the
> kernel infrastructure, then just *take* them. [...]

So I can take the mailing lists and the whole contribution
culture? Hardly...

I was not talking about code alone, I was also talking about a
social environment - which is not a one sided relationship at
all, it improves the kernel code, like it already did for over
two dozen tools/kvm originated patches:

To quote from my mail to Linus:

- Pekka listed new virtio drivers that were done via tools/kvm.

- Pekka listed ARM KVM support which was written/prototyped
using tools/kvm.

- There's over a dozen bugfixes in your kernel which were found
via syscall fuzzing built into tools/kvm. (I can dig them all
out if you want.)

- There are several fixes in the kernel side KVM subsystem
itself that were unearthed via tools/kvm.

- I showed how it helped the kernel by creating user-space
lockdep: code used in more situations means more exposure,
more bugfixes and more contributors. (It also allowed
immediate lockdep coverage for all the user-space mutexes
that tools/perf/ itself uses.)

Those were all real benefits to the kernel which are upstream or
almost upstream today.

This tool alone generated a *more* versatile number of
improvements to the kernel than the majority of filesystems and
the majority of drivers in the Linux kernel tree today has ever
achieved. "

> [...] There are loads of projects which use the kernel config
> tools, for example. There's no need to be *in* the kernel
> repo.
> And for code-reuse it's even easy enough to automatically
> extract parts of kernel code into a separate repository. [...]

... which solution would:

- lose all history
- lose contributor awareness of each other
- lose easy cross-contribution pathways

That's a severe net minus in my opinion.

I think you should try to answer the very fundamental
observation I made and the question I asked in my mail to Tytso:

We have first hand experience there: tools/perf/.

None of the predicted extreme badness happened. Yes, sometimes
we broke compatibility as ABI changes/enhancements do - but
treated them as regressions and fixed them. I also think that
considering the rate of changes our breakage ratio is very good.

So no badness happened, and in fact a lot of goodness happened:
which goodness never happened while Linux profiling was a
separate project isolated as a user-space utility!

Anyone opposing integration I think *HAS* to explain the
mechanics behind this very example in plain sight.

Why the heck has pretty much every other out of tree profiling
project died, while the in-tree one is thriving?

Yes, the key is that Arnaldo is good, and so are the other perf
contributors - and they are good because they feel at home and
they are productive. Being in the kernel repo is actually 90%
responsible for that environment!

And yes, based on the evidence I think much of perf's current
vitality would be killed off or would be severely reduced if it
was forced into a separate, out of tree project.


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