Message-ID: <20100318165435.GA9756@elte.hu>
Date:	Thu, 18 Mar 2010 17:54:35 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jes Sorensen <Jes.Sorensen@...hat.com>
Cc:	Anthony Liguori <anthony@...emonkey.ws>,
	Avi Kivity <avi@...hat.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>, Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project


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

> On 03/18/10 15:22, Ingo Molnar wrote:
> >
> >* Jes Sorensen<Jes.Sorensen@...hat.com>  wrote:
> >>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?
> 
> As I have stated repeatedly in this discussion, a unification would hurt the 
> QEMU development process because it would alienate a large number of QEMU 
> developers who are *not* Linux kernel users.

I took a quick look at the qemu.git log and more than half of all recent 
contributions came from Linux distributors.

So without KVM Qemu would be a much, much smaller project. It would be similar 
to how it was 5 years ago.

> QEMU is a lot more complex than you let on.

Please educate me then about the specifics.

> >>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)
> 
> You still haven't given us a *single* example of unification of something 
> that wasn't purely linked to the Linux kernel. perf/ oprofile is 100% linked 
> to the Linux kernel, QEMU is not. I wish you would actually look at what 
> users use QEMU for. As long as you continue to purely speculate on this, to 
> use your own words, your arguments are not holding up.

The stats show that the huge increase in Qemu contributions over the past few 
years was mainly due to KVM. Do you claim it wasnt? What other projects make 
use of it and pay developers to work on it?

> And you are not being consistent either. You have conveniently continue to 
> ignore my questions about why the file system tools are not to be merged 
> into the Linux kernel source tree?

Sorry, i didnt comment on it because the answer is obvious: the file system 
tools and pretty much any Linux-exclusive tool (such as udev) should be moved 
there. The difference is that there's not much active development done in most 
of those tools so the benefits are probably marginal. Both Qemu and KVM is 
being developed very actively though, so development model inefficiencies show 
up.

Anyway, i didnt think i'd step into such a hornet's nest by explaining what i 
see as KVM's biggest weakness today and how i suggest it to be fixed :-)

If you dont agree with me, then dont do it - no need to get emotional about 
it.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists