No kvmtool in the mainline [LWN.net]

By Jonathan Corbet
February 20, 2013

The story of the "native Linux KVM tool" (or, more recently, "kvmtool") has been playing out since early 2011. This tool serves as a simple replacement for the QEMU emulator, making it easy to set up and run guests under KVM. The kvmtool developers have been working under the assumption that their code would be merged into the mainline kernel, as was done with perf, but others have disagreed with that idea. The result has been a repetitive conversation every merge window or two as kvmtool was proposed for merging.

The conversation for the 3.9 merge window has seemingly been a bit more decisive, though. Ingo Molnar (along with kvmtool developer Pekka Enberg) presented a long list of reasons why they thought it made sense to put kvmtool into the mainline repository. Ingo even compared kernel tooling to Somalia, saying that it was made up of "disjunct entities with not much commonality or shared infrastructure", though, presumably, with fewer pirates. Few others came to the defense of kvmtool, leaving Ingo and Pekka to carry forward the argument on their own.

Linus responded that he saw no convincing reason to put kvmtool in the mainline; indeed, he thought that tying kvmtool with the kernel could be retarding its development. He concluded with:

So here, let me state it very very clearly: I will not be merging kvmtool. It's not about "useful code". It's not about the project keeping to improve. Both of those would seem to be *better* outside the kernel, where there isn't that artificial and actually harmful tie-in.

That is probably the end of the discussion unless somebody can come up with a new argument that Linus will find more convincing. At this point, it seems that kvmtool is destined to remain out of the mainline kernel repository.

Index entries for this article
Kernel	KVM
Kernel	Virtualization/KVM

to post comments

No kvmtool in the mainline

Posted Feb 21, 2013 11:54 UTC (Thu) by nhippi (subscriber, #34640) [Link] (2 responses)

The core argument seems to be "tooling and kernel side go hand in hand" and "code reuse" is not very convincing. That would suggest that fsck.* should be included in kernel tools/ directory. After all, when adding a new feature in kernel to a filesystem, you need to do the same change to filesystem's fsck tool. It is easy to see how that would end up as a long slippery slope to merging in everything from systemd to emacs...

No kvmtool in the mainline

Posted Feb 21, 2013 13:38 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

It is easy to see how that would end up as a long slippery slope to merging in everything from systemd to emacs

... when clearly the existence of the kernel-mode linux project shows that what you should be doing is running emacs in the kernel.

No kvmtool in the mainline

Posted Feb 27, 2013 1:40 UTC (Wed) by jzbiciak (guest, #5246) [Link]

Shouldn't you really just implement the kernel in EMACS LISP and be done with it? ;-)

No kvmtool in the mainline

Posted Feb 21, 2013 15:23 UTC (Thu) by deater (subscriber, #11746) [Link]

I wish he wouldn't keep pushing "perf" as an example of why putting things in the kernel is good.

After years of development perf is still missing features the perfmon2 "pfmon" utility had 5 years ago, although it has gradually been catching up.

perf didn't succeed because it was in the kernel, in fact I think that was a barrier for many people trying to develop it. perf really took off once it was included in a package by the distros, in combination with perf_event kernel support (which meant interested users didn't have to hand-patch their kernels for counter support anymore).

As someone who has spent a lot of time working on perf-related tools that aren't in the kernel it's a bit insulting to read this linux-kernel thread where all our efforts are made out to be pointless until perf came along. Especially since things like perf's possibly-soon-to-arrive named event support is going to use event tables taken from the (still developed) libpfm4 project. (Yes, the perf developers refuse to link to the libpfm4 library to get these event names, but somehow it is a good idea to strip the laboriously gathered event tables out of libpfm4, fork them, and include them in perf in a slightly different format, see: http://article.gmane.org/gmane.linux.kernel/1431566 ).

I think perf would be much better off as a separate project, it would definitely make my life as a performance counter developer easier.