Re: Enhance perf to support KVM

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 02:46 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>>> You basically have given up control over the quality of KVM by pushing so
>>> many aspects of it to user-space and letting it rot there.
>>>        
>> That's wrong on so many levels.  First, nothing is rotting in userspace,
>> qemu is evolving faster than kvm is.  If I pushed it into the kernel then
>> development pace would be much slower (since kernel development is harder),
>> quality would be lower (less infrastructure, any bug is a host crash or
>> security issue), and I personally would be totally swamped.
>>      
> That was not what i suggested tho. tools/kvm/ would work plenty fine.
>    

I'll wait until we have tools/libc and tools/X.  After all, they affect 
a lot more people and are concerned with a lot more kernel/user 
interfaces than kvm.

> As i said:
>
>    
>>> [...] You are pushing _way_ too much to user-space into different modules
>>> and maintenance domains, [...]
>>>
>>> ( Note that i dont mind user-space tooling per se, as long as it sits together
>>>    with the kernel bits and gets developed, packaged and given to the user
>>>    in the same domain. ) [...]
>>>        
>
>    
>>> Sure the design looks somewhat cleaner on paper, but if the end result is
>>> not helped by it then over-modularization sure can hurt ...
>>>        
>> Run 'rpm -qa' one of these days.  Modern software is modular, that's the
>> only way to manage it.
>>      
> Of course rpm -qa shows cases where modularization works. But my point was
> over-modularization, which due to the KVM/qemu split we all suffer from.
>    

You're the only one who suffers from it.  Everyone else is happy with 
adding features in the modules that implements them, be it kvm, qemu, 
libvirt, or virt-manager (to name one tool stack out of several).

> Modularizing along the wrong interface is worse than not modularizing
> something that could be. So when designing software you generally want to err
> on the side of _under_-modularizing. It's always very easy to split stuff up,
> when there's a really strong technical argument for it. It's very hard to pull
> the broken pieces back together though once they are in difference domains of
> maintanence - as then it's usually social integration that has to happen,
> which is always harder than a technical split-up.
>    

As it happens, the kvm and qemu development community has a large 
overlap.  Many developers read both lists, contribute to both projects, 
and participate on the same weekly call.  While we had difficulties 
pushing patches to qemu in the past, that's behind us, and qemu is now 
accepting patches at a much higher rate than kvm.

Technically, it is obvious that the userspace and kernel components are 
separate projects.  All that remains is the social divide.  Since 
everyone (except you) is mostly happy, I see no reason to change.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.