Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Ingo Molnar <mingo <at> elte.hu>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single project
Newsgroups: gmane.comp.emulators.kvm.devel
Date: Thursday 18th March 2010 11:35:27 UTC (over 7 years ago)
* Avi Kivity  wrote:

> > Still it's _very_ useful to have a single reference implementation
under 
> > tools/perf/ where we concentrate the best of the code. That is where we

> > make sure that each new kernel feature is appropriately implemented in 
> > user-space as well, that the combination works well together and is 
> > releasable to users. That is what keeps us all honest: the latency of 
> > features is much lower, and there's no ping-pong of blame going on
between 
> > the two components in case of bugs or in case of misfeatures.
> 
> That would make sense for a truly minimal userspace for kvm: we once had
a 
> tool called kvmctl which was used to run tests (since folded into qemu). 
It 
> didn't contain a GUI and was unable to run a general purpose guest.  It
was 
> a few hundred lines of code, and indeed patches to kvmctl had a much
closer 
> correspondence to patches with kvm (though still low, as most kvm patches

> don't modify the ABI).

If it's functional to the extent of at least allowing say a serial console
via 
the console (like the UML binary allows) i'd expect the minimal user-space
to 
quickly grow out of this minimal state. The rest will be history.

Maybe this is a better, simpler (and much cleaner and less controversial) 
approach than moving a 'full' copy of qemu there.

There's certainly no risk: if qemu stays dominant then nothing is lost 
[tools/kvm/ can be removed after some time], and if this clean base works
out 
fine then the useful qemu technologies will move over to it gradually and 
without much fuss, and the developers will move with it as well.

If it's just a token effort with near zero utility to begin with it
certainly 
wont take off.

Once it's there in tools/kvm/ and bootable i'd certainly hack up some quick

xlib based VGA output capability myself - it's not that hard ;-) It would
also 
allow me to test whether latest-KVM still boots fine in a much simpler way.

(most of my testboxes dont have qemu installed)

So you have one user signed up for that already ;-)

> > Same goes for KVM+Qemu: it would be so much nicer to have a single, 
> > well-focused reference implementation under tools/kvm/ and have 
> > improvements flow into that code base.
> >
> > That way KVM developers cannot just shrug "well, GUI suckage is a 
> > user-space problem" - like the answers i got in the KVM usability
thread 
> > ...
> >
> > The buck will stop here.
> 
> Suppose we copy qemu tomorrow into tools/.  All the problems will be
copied 
> with it.  Someone still has to write patches to fix them. Who will it be?

What we saw with tools/perf/ was that pure proximity to actual kernel
testers 
and kernel developers produces a steady influx of new developers. It didnt 
happen overnight, but it happened. A simple:

  cd tools/perf/
  make -j install

Gets them something to play with. That kind of proximity is very powerful.

The other benefit was that distros can package perf with the kernel
package, 
so it's updated together with the kernel. This means a very efficient 
distribution of new technologies, together with new kernel releases.

Distributions are very eager to update kernels even in stable periods of
the 
distro lifetime - they are much less willing to update user-space packages.

You can literally get full KVM+userspace features done _and deployed to
users_ 
within the 3 months development cycle of upstream KVM.

All these create synergies that are very clear once you see the process in 
motion. It's a powerful positive feedback loop. Give it some thought
please.

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