Re: KVM usability

Zachary Amsden
2010-03-01T22:08:39Z

On 03/01/2010 11:45 AM, Anthony Liguori wrote:
> On 03/01/2010 02:56 PM, Ingo Molnar wrote:
>
>> - Code distribution is easy: it comes with the kernel. This spreads
>> the code
>> far and wide. It's easy for kernel developers to jump in and help
>> out, the
>> latest devel code is always there, a single 'cd tools/perf/; make
>> -j install'
>> command away.
>> - Code reuse: we started sharing/librarizing code with the kernel:
>> bitmap.h,
>> hash.h, list.h, rbtree.h, bitops.h, prefetch.h.
>
> You could argue that any project should be in the kernel for these
> reasons. I see no reason why something as like KVM should be part of
> the kernel and udev shouldn't be.

gcc and the kernel are quite closely coupled, btw.

>
>> etc.
>>
>> In the KVM context this was obviously only a suggestion though. If i
>> were
>> hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the
>> project has
>> very close ties to kernel-KVM and repo level unification would create
>> various
>> synergies - but you are hacking on it, not me ;-)
>>
>> If i were doing it i'd probably start with a cleaned up and stripped
>> down
>> version of Qemu, to make it eligible for mainline kernel inclusion.
>
> You should try it. I think you'll find that it's not as obvious thing
> to do as you think it is.

Yes. Yes.

We've all looked at the hulking hairy behemoth of qemu and said, I think
I can clean this beast up and make him look like a proper gentlemen.
Then we tried to shave off the excess hair, only to find not only did it
grow back as fast as we trimmed it, but his complexion underneath was
mottled and inconsistent, so much so that the hair was actually helping.

In the end, we just settled for dressing him up in a suit and tie.

Zach