Merging the kvm tool
Posted Aug 29, 2011 13:23 UTC (Mon) by
pbonzini (subscriber, #60935)
Parent article:
Merging the kvm tool
I must say I have never read a worse article on LWN. Take it as a compliment, as I have learnt so much from LWN that I just cannot enumerate everything. Also, Jon is in all likelihood not the only one that has misunderstood the matter, so it probably helps other people if some of the problematic points in the article are corrected.
Here is a short list of observations:
NLKT was started in response to unhappiness about QEMU, the state of its code, and the pace of its development: NLKT was started in response to Ingo complaining about QEMU and because it's undoubtedly fun to hack on, but no one ever constructed any proof of the problems with QEMU. The command-line problem is obviously solvable with a simple wrapper script.
NLKT is meant to be able to boot a basic Linux kernel without the need for a BIOS image or much in the way of legacy hardware emulation: It's worse than that. NLKT doesn't emulate anything close to a modern PC. For example, it does not support ACPI. This means that even if it is mostly touted as a developer tool, developers of some subsystems would still not be able to use it (unlike QEMU). NLKT is also developing hardware models against Linux kernel source code rather than against the spec; this is very wrong because it is vulnerable to improvements to the drivers. In fact, when QEMU did it this way, newer versions of Linux and/or Windows revenged later (one example is in the ATAPI implementation).
Everybody seems to think that NLKT is a useful tool; nobody objects to its existence. As you correctly point out later in the article, for KVM developers the NLKT is useful because it's an independent user of the same ABI. But for the general public (developers and users) it's about as useful as lguest; it would be useful as a proof of concept tool, but the NLKT developers are expanding it way beyond that. At the same time, they are leaving out features that would obviously be very useful for Linux kernel developers. For example, NLKT does not support a gdbstub for totally transparent debugging of guest kernels.
It is also seemingly viewed by some as a move to be the "official" hardware emulator for KVM: it's open source and we all know that there is nothing "official" but what people use. NLKT so far has 10% of the features that are needed to test real-world guests (all of them, not just Linux), which in turn is what is needed to test KVM kernel changes.
like perf, NLKT is closely tied to the kernel and heavily used by kernel developers". But perf is used a lot by non-kernel developers as a profiling tool. NLKT simply won't work for most Linux enthusiasts who want to check out FreeBSD every once in a while, or have some hardware with Windows-only drivers.
Another problem is that while NLKT is indeed getting some things right, it is doing too many mistakes that QEMU already did, and its roadmap includes too many features that contradict its original goal. From the recent talk at KVM forum, Grub support stands out: a boot loader is all about legacy device support.
there is no proof that perf would not have been nearly as successful outside of the mainline tree as it has been internally: There is actually no proof for this. Unlike oprofile, perf was developed by several core kernel maintainers. It seems to me like a much stronger factor impacting the success of perf vs. oprofile.
You even say That success seems to be one of the things that opponents are worried about, but that's absolutely not a factor. Everybody is amazed at the lengths at which NLKT has come, but still NLKT is a solution in search of a problem (except if your problem is to find something fun to hack on, of course! :). The kernel component of KVM is very mature, and so is the ABI. Unlike perf, KVM would not have benefits from forcing lockstep upgrades of the kernel and userspace components. The part of KVM that is more in flux is the host-guest ABI, which you must preserve anyway since you cannot break compatibility with existing guests.
NLKT is also repeating the same mistakes as early QEMU, and a few others: for example, unlike KVM itself, NLKT is strictly limited to x86. While undoubtedly a burden for QEMU developers, non-x86 support helps keeping you honest about the specs you are trying to implement, and it can also be extremely helpful for kernel developers. (A few years ago Ingo was suggesting that Linux be compiled with its own compiler, but now he objects to QEMU because it includes a just-in-time compiler ;)). See also the point above about developing hardware models against Linux kernel source code.
I hope this long comment helps understanding the situation better. I look forward to the replies!
(
Log in to post comments)
