Re: Enhance perf to support KVM

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 03:16 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>>> 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.
>>      
> So your answer can be summed up as: 'we wont do what makes sense technically
> because others suck even more' ?
>    

I can sum up your this remark as 'whenever you disagree with me, I will 
rephrase your words to make you look like an idiot'.

If you believe I'm an idiot, there's no need to have this (or any) 
conversation.  If not, please refrain from this type of verbal gymnastics.

> And it's not just the kernel<->user interface (which btw., for the case of X
> is far narrower than what KVM currently has to Qemu).
>
> The issue is a basic question of software design: does kvm-qemu really make as
> much sense without the kernel component as with it? The answer is: it will
> borderline-work with CPU emulation (and i'm sure there are people making use
> of it that way), but 90%+ of the userbase uses it with KVM and vice versa. It
> is really a single logical component as far as maintenance goes, and
> tools/kvm/ would make quite a bit of sense.
>    

There are two separate questions.  Is there room for a kvm-only 
userspace component?  I believe so, but throwing away the momentum 
behind qemu would be foolish.

Does it make sense for such a component to live in linux.git?  IMO, no, 
and certainly a lot less than libc and X.

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