Re: Enhance perf to support KVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/26/2010 04:23 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx>  wrote:

On 02/26/2010 03:16 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx>   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.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux