Message-ID: <20100322134633.GD1940@8bytes.org>
Date:	Mon, 22 Mar 2010 14:46:33 +0100
From:	Joerg Roedel <joro@...tes.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Avi Kivity <avi@...hat.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"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>,
	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

On Mon, Mar 22, 2010 at 01:22:28PM +0100, Ingo Molnar wrote:
> 
> * Joerg Roedel <joro@...tes.org> wrote:
> 
> > [...] Basically the reason of the oProfile failure is a disfunctional 
> > community. [...]
> 
> Caused by: repository separation and the inevitable code and social fork a 
> decade later.

No, the split-repository situation was the smallest problem after all.
Its was a community thing. If the community doesn't work a single-repo
project will also fail. Look at the state of the alpha arch in Linux
today, it is maintained in one repository but nobody really cares about
it. Thus it is miles behine most other archs Linux supports today in
quality and feature completeness.

> What you fail to realise (or what you fail to know, you werent around when 
> Oprofile was written, i was) is that Oprofile _did_ have a functional single 
> community when it was written. The tooling and the kernel bits was written by 
> the same people.

Yes, this was probably the time when everybody was enthusiastic about
the feature and they could attract lots of developers. But situation
changed over time.

> So i dont see much of a difference to the Oprofile situation really and i see 
> many parallels. I also see similar kinds of desktop usability problems.

The difference is that KVM has a working community with good developers
and maintainers.

> The difference is that we dont have KVM with a decade of history and we dont 
> have a 'told you so' KVM reimplementation to show that proves the point. I 
> guess it's a matter of time before that happens, because Qemu usability is so 
> absymal today - so i guess we should suspend any discussions until that 
> happens, no need to waste time on arguing hypoteticals.

We actually have lguest which is small. But it lacks functionality and
the developer community KVM has attracted.

> I think you are rationalizing the status quo.

I see that there are issues with KVM today in some areas. You pointed
out the desktop usability already. I personally have trouble with the
qem-kvm.git because it is unbisectable. But repository unification
doesn't solve the problem here.
The point for a single repository is that it simplifies the development
process. I agree with you here. But the current process of KVM is not
too difficult after all. I don't have to touch qemu sources for most of
my work on KVM.

> It's as if you argued in 1990 that the unification of East and West Germany 
> wouldnt make much sense because despite clear problems and incompatibilites 
> and different styles westerners were still allowed to visit eastern relatives 
> and they both spoke the same language after all ;-)

Um, hmm. I don't think these situations have enough in common to compare
them ;-)

	Joerg



--
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