Re: KVM usability

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/01/2010 02:56 PM, Ingo Molnar wrote:
> Here's our experience with tools/perf/. Hosting the project in the kernel
> proper helped its quality immensely:
>
>   - It's much easier to synchronize new features on the kernel side and on the
>     user-space side. The two go hand in hand - they are often implemented in
>     the same patch.
>    

Kernel features and qemu features usually don't have a great amount of 
intersect.  All of the problems you've described are strictly in the 
qemu space.

>   - It's released together with the kernel, which gives a periodic 3 months
>     release frequency. Not too slow, not too fast.
>    

qemu release range in length from 3-6 months depending on distribution 
schedules.  They are very regular.

>   - Lots of eyeballs and interest. In its mere 8 months of existence
>     tools/perf/ has attracted more than 60 contributors already, and 35 KLOC of
>     new code has been written.
>    

In our last release, we had around 100 contributors and about 100 KLOC 
of code written.  We've got a lot of eyeballs and a lot of interest.

>   - Code quality requirements are that of the kernel's. No muck allowed and
>     it's not hard to explain what kind of code is preferred.
>    

Code quality is subjective.  We have a different coding style.

>   - Tool breakage bisection is a breeze: there's never any mismatch between
>     tools/perf and the kernel counterpart. With a separate package we'd
>     have more complex test and bisection scenarios.
>    

KVM has a backwards compatible ABI so there's no such thing as mismatch 
between user and kernel space.

>   - 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.

> 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.

Regards,

Anthony Liguori

> 	Ingo
>