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

[Avi Kivity]

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@xxxxxxx>
> | 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/