Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Avi Kivity <avi@redhat.com>]

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@amd.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