Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Ingo Molnar <mingo@elte.hu>]

* Jes Sorensen <Jes.Sorensen@redhat.com> wrote:

> On 03/18/10 11:58, Ingo Molnar wrote:
> >
> >* Jes Sorensen<Jes.Sorensen@redhat.com>  wrote:
> >>Thats a very glorified statement but it's not reality, sorry. You can do
> >>that with something like perf because it's so small and development of perf
> >>is limited to a very small group of developers.
> >
> > I was not talking about just perf: i am also talking about the arch/x86/ 
> > unification which is 200+ KLOC of highly non-trivial kernel code with 
> > hundreds of contributors and with 8000+ commits in the past two years.
> 
> Sorry but you cannot compare merging two chunks of kernel code that 
> originated from the same base, with the efforts of mixing a large userland 
> project with a kernel component. Apples and oranges.

That's true to a certain degree, but combined with the perf experience it's 
all rather clear.

Similar arguments were made against the x86 unification and against perf. 
Similar arguments were made against KVM and in favor of Xen years ago - back 
when few of you knew about it ;-)

These are all repeating patterns in my experience.

You could fairly contrast that with a _failed_ unification perhaps - but i'm 
not aware of any such failed unification. (please educate me if you are)

The thing is, unifications are rare in the OSS space not because they dont 
make sense technically (to the contrary), they are rare due to blind inertia 
(why change if we managed to muddle through with the current scheme?) and to a 
certain degree due to the egos involved ;-)

As such we have a proliferation of packages in Linux, and we'd be much better 
off in a more focused fashion. And whenever i see that in the kernel's context 
i'll mention it - as it happened here too.

> > Also, it applies to perf as well: people said exactly that a year ago: 
> > 'perf has it easy to be clean as it is small, once it gets as large as 
> > Oprofile tooling it will be in the same messy situation'.
> >
> > Today perf has more features than Oprofile, has a larger and more complex 
> > code base, has more contributors, and no, it's not in the same messy 
> > situation at all.
> 
> Both perf and oprofile are still relatively small projects in comparison to 
> QEMU.

So is your argument that the unification does not make sense due to size? 
Would a smaller Qemu be more appropriate for this purpose?

> > So whatever you think of large, unified projects, you are quite clearly 
> > mistaken. I have done and maintained through two different types of 
> > unifications and the experience was very similar: both developers and 
> > users (and maintainers) are much better off.
> 
> You believe that I am wrong in my assessment of unified projects, and I 
> obviously think you are mistaken and underestimating the cost and effects of 
> trying to merge the two.
> 
> Well I think we are just going to agree to disagree on this one. I am not 
> against merging projects where it makes sense, but in this particular case I 
> am strongly convinced the loss would be much greater than the gain.

I wish you said that based on first hand negative experience with 
unifications, not based on just pure speculation.

(and yes, i speculate too, but at least with some basis)

	Ingo