* Avi Kivity <avi@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
