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

[Ingo Molnar <mingo@kernel.org>]

* David Woodhouse <dwmw2@infradead.org> 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.

Thanks,

	Ingo