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

[Avi Kivity <avi@redhat.com>]

On 03/22/2010 04:47 PM, Ingo Molnar wrote:
>
>>> If you are interested in the first-hand experience of the people who are
>>> doing the perf work then here it is: by far the biggest reason for perf
>>> success and perf usability is the integration of the user-space tooling
>>> with the kernel-space bits, into a single repository and project.
>>>        
>> Please take a look at the kvm integration code in qemu as a fraction of the
>> whole code base.
>>      
> You have to admit that much of Qemu's past 2-3 years of development was
> motivated by Linux/KVM (i'd say more than 50% of the code).

kvm certainly revitalized qemu development.

> As such it's one
> and the same code base - you just continue to define Qemu to be different from
> KVM.
>    

It's not the same code base.  kvm provides a cpu virtualization service, 
qemu uses it.  There could be other users.  qemu could go away one day 
and be replaced by something else (tools/kvm?), and kvm would be unaffected.

> I very much remember how Qemu looked like _before_ KVM: it was a struggling,
> dying project. KVM clearly changed that.
>    

I'm a hero.

>>> The very move you are opposing so vehemently for KVM.
>>>        
>> I don't want to fracture a working community.
>>      
> Would you accept (or at least not NAK) a new tools/kvm/ tool that builds
> tooling from grounds up, while leaving Qemu untouched? [assuming it's all
> clean code, etc.]
>    

I couldn't NAK tools/kvm any more than I could NAK a new project outside 
the kernel repository.  IMO it would be duplicated effort, but like I 
mentioned before, I can't tell volunteers what to do, only recommend 
that they join the existing effort.

> Although i have doubts about how well that would work 'against' your opinion:
> such a tool would need lots of KVM-side features and a positive attitude from
> you to be really useful. There's a lot of missing functionality to cover.
>    

Functionality that can be implemented in userspace will not be accepted 
into kvm unless there are very good reasons why it should be.  Things 
that belong in kvm will be more than welcome.

>> Seems like perf is also split, with sysprof being developed outside the
>> kernel.  Will you bring sysprof into the kernel?  Will every feature be
>> duplicated in prof and sysprof?
>>      
> I'd prefer if sysprof merged into perf as 'perf view' - but its maintainer
> does not want that - which is perfectly OK.

You spared him the flamewar, I hope.

> So we are building equivalent
> functionality into perf instead.
>    

Ah, duplicating effort.  Great.

> Think about it like Firefox plugins: the main Firefox project picks up the
> functionality of the most popular Firefox plugins all the time. Session Saver,
> Tab Mix Plus, etc. were all in essence 'merged' (in functionality, not in
> code) into the 'reference' Firefox project.
>    

There's a difference between absorbing a small plugin and duplicating a 
project.

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