Date:	Mon, 22 Mar 2010 19:44:11 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Joerg Roedel <joro@...tes.org>,
	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 03/22/2010 06:32 PM, Ingo Molnar wrote:
>
> So, what do you think creates code communities and keeps them alive?
> Developers and code. And the wellbeing of developers are primarily influenced
> by the repository structure and by the development/maintenance process - i.e.
> by the 'fun' aspect. (i'm simplifying things there but that's the crux of it.)
>    

There is nothing fun about having one repository or two.  Who cares 
about this anyway?

tools/kvm/ probably will draw developers, simply because of the glory 
associated with kernel work.  That's a bug, not a feature.  It means 
that effort is not distributed according to how it's needed, but because 
of irrelevant considerations.

> I simply do not want to see KVM face the same fate, and yes i do see similar
> warnings signs.
>    

The number of kvm and qemu developers keeps increasing.

We're having a kvm forum in August where we all meet.  Come and see for 
yourself.

>> We actually have lguest which is small. But it lacks functionality and the
>> developer community KVM has attracted.
>>      
> I suggested long ago to merge lguest into KVM to cover non-VMX/non-SVM
> execution.
>    

Rusty posted some initial patches for pv-only kvm but he lost interest 
before they were completed.  No one followed up.

btw, lguest has a single repository, userspace and kernel in the same 
repository, yet is practically dead.

>>> 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.
>>      
> Why doesnt it solve the bisectability problem? The kernel repo is supposed to
> be bisectable so that problem would be solved.
>    

These days qemu-kvm.git is bisectable (though not always trivially).  
qemu.git doesn't have this problem.

>> 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.
>>      
> In my judgement you'd have to do that more frequently, if KVM was properly
> weighting its priorities. For example regarding this recent KVM commit of
> yours:
>
> | commit ec1ff79084fccdae0dca9b04b89dcdf3235bbfa1
> | Author: Joerg Roedel<joerg.roedel@....com>
> | Date:   Fri Oct 9 16:08:31 2009 +0200
> |
> |     KVM: SVM: Add tracepoint for invlpga instruction
> |
> |     This patch adds a tracepoint for the event that the guest
> |     executed the INVLPGA instruction.
>
> With integrated KVM tooling i might have insisted for that new tracepoint to
> be available to users as well via some more meaningful tooling than just a
> pure tracepoint.
>    

Something I've wanted for a long time is to port kvm_stat to use 
tracepoints instead of the home-grown instrumentation.  But that is 
unrelated to this new tracepoint.  Other than that we're satisfied with 
ftrace.

> You should realize that naturally developers will gravitate towards the most
> 'fun' aspects of a project. It is the task of the maintainer to keep the
> balance between fun and utility, bugs and features, quality and code-rot.
>    

There are plenty of un-fun tasks (like fixing bugs and providing RAS 
features) that we're doing.  We don't do this for fun but to satisfy our 
users.

-- 
error compiling committee.c: too many arguments to function

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