Message-ID: <20100318092232.GC2157@elte.hu>
Date:	Thu, 18 Mar 2010 10:22:32 +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:

> >  - move a clean (and minimal) version of the Qemu code base to tools/kvm/, 
> >    in the upstream kernel repo, and work on that from that point on.
> 
> I'll ignore the repository location which should be immaterial to a serious 
> developer and concentrate on the 'clean and minimal' aspect, since it has 
> some merit.  [...]

To the contrary, experience shows that repository location, and in particular 
a shared repository for closely related bits is very much material!

It matters because when there are two separate projects, even a "serious 
developer" is finding it double and triple difficult to contribute even 
trivial changes.

It becomes literally a nightmare if you have to touch 3 packages: kernel, a 
library and an app codebase. It takes _forever_ to get anything useful done.

Also, 'focus on a single thing' is a very basic aspect of humans, especially 
those who do computer programming. Working on two code bases in two 
repositories at once can be very challenging physically and psychically.

So what i've seen is that OSS programmers tend to pick a side, pretty much 
randomly, and then rationalize it in hindsight why they prefer that side ;-)

Most of them become either a kernel developer or a user-space package 
developer - and then they specialize on that field and shy away from changes 
that involve both. It's a basic human thing to avoid the hassle that comes 
with multi-package changes. (One really has to be outright stupid, fanatic or 
desperate to even attempt such changes these days - such are the difficulties 
for a comparatively low return.)

The solution is to tear down such artificial walls of contribution where 
possible. And tearing down the wall between KVM and qemu-kvm seems very much 
possible and the advantages would be numerous.

Unless by "serious developer" you meant: "developer willing to [or forced to] 
waste time and effort on illogically structured technology".

> [...]
>
> Do you really think the echo'n'cat school of usability wants to write a GUI?  
> In linux-2.6.git?

Then you'll be surprised to hear that it's happening as we speak and the 
commits are there in linux-2.6.git. Both a TUI and GUI is in the works.

Furthermore, the numbers show that half of the usability fixes to tools/perf/ 
came not from regular perf contributors but from random kernel developers and 
testers who when they build the latest kernel and try out perf at the same 
time (it's very easy because you already have it in the kernel repository - no 
separate download, no installation, etc. necessary).

I had literally zero such contributions when (the precursor to) 'perf' was 
still a separate user-space project.

You could have the same effect for Qemu: the latest bits in tools/kvm/ would 
be built by regular kernel testers and developers. The integration benefits 
dont just extend to developers, a unified project is vastly easier to test as 
well.

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