Re: KVM usability

[Ingo Molnar <mingo@elte.hu>]

* Zachary Amsden <zamsden@redhat.com> wrote:

> > I guess there is some misunderstanding here, the tools/ directory that 
> > lives in the kernel _sources_, has no kernel source, its all userspace 
> > stuff.
> 
> Yeah, no morning coffee :=)
> 
> So instead we are advocating forking qemu into the kernel.  That makes even 
> less sense.  It's not sustainable or eco-friendly to either community.

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.

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

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

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

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

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

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.

	Ingo