Re: KVM usability

Anthony Liguori
2010-03-01T21:45:13Z

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
>