* Avi Kivity wrote:
> > Still it's _very_ useful to have a single reference implementation
> > 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
> > 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
> tool called kvmctl which was used to run tests (since folded into qemu).
> didn't contain a GUI and was unable to run a general purpose guest. It
> a few hundred lines of code, and indeed patches to kvmctl had a much
> 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
the console (like the UML binary allows) i'd expect the minimal user-space
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
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
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
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
> > ...
> > The buck will stop here.
> Suppose we copy qemu tomorrow into tools/. All the problems will be
> 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
and kernel developers produces a steady influx of new developers. It didnt
happen overnight, but it happened. A simple:
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
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
distro lifetime - they are much less willing to update user-space packages.
You can literally get full KVM+userspace features done _and deployed to
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
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html