Message-ID: <20100318085607.GB2157@elte.hu>
Date:	Thu, 18 Mar 2010 09:56:07 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	Anthony Liguori <anthony@...emonkey.ws>,
	"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>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.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


* Avi Kivity <avi@...hat.com> wrote:

> On 03/17/2010 10:10 AM, Ingo Molnar wrote:
> >
> >> It's about who owns the user interface.
> >>
> >> If qemu owns the user interface, than we can satisfy this in a very 
> >> simple way by adding a perf monitor command.  If we have to support third 
> >> party tools, then it significantly complicates things.
> >
> > Of course illogical modularization complicates things 'significantly'.
> 
> Who should own the user interface then?

If qemu was in tools/kvm/ then we wouldnt have such issues. A single patch (or 
series of patches) could modify tools/kvm/, arch/x86/kvm/, virt/ and 
tools/perf/.

Numerous times did we have patches to kernel/perf_event.c that fixed some 
detail, also accompanied by a tools/perf/ patch fixing another detail. Having 
a single 'culture of contribution' is a powerful way to develop.

It turns out kernel developers can be pretty good user-space developers as 
well and user-space developers can be pretty good kernel developers as well. 
Some like to do both - as long as it's all within a single project.

The moment any change (be it as trivial as fixing a GUI detail or as complex 
as a new feature) involves two or more packages, development speed slows down 
to a crawl - while the complexity of the change might be very low!

Also, there's the harmful process that people start categorizing themselves 
into 'I am a kernel developer' and 'I am a user space programmer' stereotypes, 
which limits the scope of contributions artificially.

> > Fast forward to 2010. The kernel side of KVM is maximum goodness - by far 
> > the worst-quality remaining aspects of KVM are precisely in areas that you 
> > mention: 'if we have to support third party tools, then it significantly 
> > complicates things'. You kept Qemu as an external 'third party' entity to 
> > KVM, and KVM is clearly hurting from that - just see the recent KVM 
> > usability thread for examples about suckage.
> 
> Any qemu usability problems are because developers (or their employers) are 
> not interested in fixing them, not because of the repository location.  Most 
> kvm developer interest is in server-side deployment (even for desktop 
> guests), so there is limited effort in implementing a virtualbox-style GUI.

The same has been said of oprofile as well: 'it somewhat sucks because we are 
too server centric', 'nobody is interested in good usability and oprofile is 
fine for the enterprises'. Ironically, the same has been said of Xen usability 
as well, up to the point KVM came around.

What was the core of the problem was a bad design and a split kernel-side 
user-side tool landscape.

In fact i think saying that 'our developers only care about the server' is 
borderline dishonest, when at the same time you are making it doubly sure (by 
inaction) that it stays so: by leaving an artificial package wall between 
kernel-side KVM and user-side KVM and not integrating the two technologies.

You'll never know what heights you could achieve if you leave that wall there 
...

Furthermore, what should be realized is that bad usability hurts "server 
features" just as much. Most of the day-to-day testing is done on the desktop 
by desktop oriented testers/developers. _Not_ by enterprise shops - they tend 
to see the code years down the line to begin with ...

Yes, a particular feature might be server oriented, but a good portion of our 
testing is on the desktop and everyone is hurting from bad usability and this 
puts limits on contribution efficiency.

As the patch posted in _this very thread demonstrates it_, it is doubly more 
difficult to contribute a joint KVM+Qemu feature, because it's two separate 
code bases, two contribution guidelines, two release schedules. While to the 
user it really is just one and the same thing. It should be so for the 
developer as well.

Put in another way: KVM's current split design is making it easy to contribute 
server features (because the kernel side is clean and cool), but also makes it 
artificially hard to contribute desktop features: because the tooling side 
(Qemu) is 'just another package', is separated by a package and maintenance 
wall and is made somewhat uncool by a (as some KVM developers have pointed out 
in this thread) quirky codebase.

(the rest of your points are really a function of this fundamental 
disagreement)

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