Re: Enhance perf to support KVM

Avi Kivity
2010-02-26T15:07:45Z

On 02/26/2010 04:23 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> wrote:
>
>
>> 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'.
>>
> Two points:
>
> 1)
>
> You can try to ridicule me if you want,

I'd much prefer it if if no ridiculing was employed on either side.

> but do you actually claim that my
> summary is inaccurate?
>
> I do claim it's a substantially accurate summary: you said you will (quote:)
> "wait with tools/kvm/ until we have tools/libc and tools/X".
>
> I do think tools/X and tools/libc would make quite a bit of sense - this is
> one of the better design aspects of FreeBSD et al. It's a mistake that it's
> not being done.
>

There are arguments for libc to be developed in linux-2.6.git, and
arguments against. The fact is that they are not, so presumably the
arguments against plus inertia outweigh the arguments for.

The same logic holds for kvm, except that there are less arguments for
development in linux-2.6.git. Only a small part of qemu is actually
concerned with kvm; most of it is mucking around with X, emulating old
devices, emulating instruction sets (irrelevant for tools/kvm) and doing
boring managementy stuff.

Do we really want to add several hundered thousand lines to Linux, only
a few thousand or of which talk to the kernel?

> 2)
>
> I used a question mark (the sentence was not a statement of fact), and you
> have no obligation to agree with the summary i provided.
>
>

Thanks. I hope you don't agree with it either.

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