Ingo Molnar wrote: > * 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 ;-) > Alright, you just volunteered. Just give it a go and try to implement the "oh so simple" KVM frontend while maintaining compatibility with at least a few older Linux guests. My guess is that you'll realize it's a dead end before committing anything to the kernel source tree. But really, just try it out. Good Luck Alex -- 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
