| |||||||||||||
KVM, QEMU, and kernel project managementKVM, QEMU, and kernel project managementPosted Mar 23, 2010 21:49 UTC (Tue) by mingo (subscriber, #31122)In reply to: KVM, QEMU, and kernel project management by drag Parent article: KVM, QEMU, and kernel project management
Nice observations, i agree with most of them. Just wanted to react to this bit:
What i suggested was to move it into the kernel repository (maybe you understood it as such), but still as a user-space project - a'la tools/perf/. That is a plain user-space tool that lives in the kernel repository. It can be built and installed in user-space by doing: cd tools/perf/ make -j installAnd it's a regular Linux app. It is an admittedly very unusual development model to maintain a user-space tool within the kernel repository, but for such a tool with such close ties to the Linux kernel as perf there are many advantages, and it worked out well beyond our expectations. Thanks, Ingo [*] with the caveat that it does make sense to move certain device emulation and paravirt functionality into the kernel, and not emulate it straight from Qemu. Many performance problems of KVM result from excessive execution in Qemu.
(Log in to post comments)
KVM, QEMU, and kernel project management Posted Mar 23, 2010 22:25 UTC (Tue) by ejr (subscriber, #51652) [Link]
Very unusual development model. So unusual that it's been how *BSD and Solaris have functioned, well, forever.
KVM, QEMU, and kernel project management Posted Mar 23, 2010 22:59 UTC (Tue) by mingo (subscriber, #31122) [Link] AFAIK it's still quite different from the FreeBSD model. Last i checked (which, admittedly, was many years ago) in FreeBSD a kernel developer with commit access did not have commit access to a user-space package - and vice versa. So it's not really a unified repository in the same way that tools/perf/ is. Plus, most of the user-space packages are imported into FreeBSD and are maintained externally (with local changes applied), so any local changes would have to be contributed back to the upstream project - eliminating most of the unification gains i talked about in the KVM discussion. In any case, my FreeBSD development model knowledge is pretty outdated, so if the model has changed (or if it never existed in that form) please correct me and educate me ... Plus, just to make it clear: i find the integrated repository aspect of FreeBSD rather useful, and i think Linux should learn from that. Thanks, Ingo
Minimal userspace for kvm in linux-2.6.git Posted Mar 24, 2010 0:03 UTC (Wed) by jrn (subscriber, #64214) [Link] As an innocent bystander, I really liked this suggestion that Avi Kivity made and you picked up: 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. I still hope it happens.
Minimal userspace for kvm in linux-2.6.git Posted Mar 24, 2010 12:14 UTC (Wed) by nescafe (subscriber, #45063) [Link]
yeah, having a minimal overhead userspace tool that provides just enough to give me a serial console and the virtio drivers would handle most of my VM needs.
It's just not that simple to build userspace binaries that use lots of libraries Posted Mar 24, 2010 8:45 UTC (Wed) by ringerc (subscriber, #3071) [Link] That is a plain user-space tool that lives in the kernel repository. It can be built and installed in user-space by doing: That's exactly what they can't do, because building real world GUI-using userspace binaries isn't that simple. You need a monster like autoconf or CMake to do the grunt work of locating the large variety of (mostly GUI-related) libraries apps like qemu need to link to to achieve the functionality people expect of them. The day I see a makefile.am and configure.in or a CMakeLists.txt in the kernel tree ... Look at the output of: To be able to keep the core kvm userspace code in the kernel tree, they'd probably have to rip up kvm into a core libkvm.so and "the rest". libkvm.so would be usable by an extremely stripped down GUI-less sound-less ....-less kvm-basic that could also be built by simple makefile and stored in the kernel tree. It'd also be used by a full-featured kvm maintained elsewhere and built with regular build tools. It doesn't seem like any improvement to me, it just moves the interface boundary a bit. I (as joe random) happen to share your general sentiment that some userspace really could use being kept in the kernel. udev or whatever device management daemon of the day is used; module-init-tools; etc. I just don't think it's realistic to put kvm in that group unless it does prove useful to move the interface boundary into a user-space library, ie stable library ABI for library shipped with kernel, unstable kernel ABI for talking to that library. And good luck getting that past the stable-kernel-ABI dragons.
It's just not that simple to build userspace binaries that use lots of libraries Posted Mar 25, 2010 12:39 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] You need a monster like autoconf or CMake to do the grunt work of locating the large variety of (mostly GUI-related) libraries... These days most popular libraries support pkg-config which makes this a whole lot simpler.
It's just not that simple to build userspace binaries that use lots of libraries Posted Mar 26, 2010 3:32 UTC (Fri) by ringerc (subscriber, #3071) [Link]
True, and pkg-config has come a long way lately with things like variable support and even msvc syntax handling. It doesn't help very much if you need to test for build options, though there's no reason why it *can't*. pkg-config's --variable feature would let you do build option tests ... but far too many packages fail to set appropriate .pc variables for important build options.
At least pkg-config makes version tests, cflags discovery, etc a whole lot easier.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 8:49 UTC (Wed) by ringerc (subscriber, #3071) [Link] ... though re-reading your comment, you're in fact correcting a prior misunderstanding and pointing out that you're *not* suggesting putting it in the kernel tree and by extension kernel build system, just in the kernel repo. Sorry. Thrown by your analogy to perf - because it's not really like perf at all.
|
|||||||||||||