Date:	Sat, 9 Feb 2013 01:57:27 +0200
From:	Pekka Enberg <penberg@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	David Rientjes <rientjes@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sasha Levin <levinsasha928@...il.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Michal Marek <mmarek@...e.cz>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

Linus,

I'm going to go out on a limb here and say that this might the odd out
case that's not really supposed to happen where *you* are just WRONG,
CRAZY, and IGNORING REALITY.

On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> I think merging it would be an active mistake, and would just tie two
> projects together that just shouldn't be tied together.

The two are already tied together - that was the whole premise of the
project!

What Ingo proposed two years ago was to implement a (simple) userspace
counterpart of KVM under tools/kvm using kernel development process
and reusing kernel code as much as possible. He predicted that we'd
eventually have:

  - a clean codebase that's accessible to new developers

  - new kernel features developed in 'lock-step' with the userspace code

  - encouraged kernel developers to write userspace code

As it turns out, Ingo's predictions were correct. We support KVM on
ARMv8 even before the in-kernel code has hit mainline. People
implemented vhost drivers in lock-step. Most of the contributors are
also kernel developers. And we in fact have a clean codebase that's
accessible to anyone who knows the kernel coding style.

I honestly don't see any of these things happening had we not taken the
path suggested by Ingo early on.

On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> The fact that kvmtool isn't available as a standalone project probably
> keeps people actively from using it. You can't just fetch kvmtool. You
> have to fetch the kernel and kvmtool, and if you're a kernel developer
> you either have to make a whole new kernel tree for it (which is
> stupid) or merge it into your normal kernel tree that has development
> that has nothing to do with kvmtool (which is stupid AND F*CKING
> INSANE)

Actually, as a kernel developer, you don't need to do that. You can
'make install' from a kvmtool branch and leave it at that - just like
with perf. [ And if it was in your tree, you'd wouldn't even need the
branch ;-). ]

And yes, you are absolutely correct that living in the kernel tree is
suboptimal for the casual user. However, it's a trade-off to make
tools/kvm *development* easier especially when you need to touch both
kernel and userspace code.

On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> "git" is a hell of a lot more useful utility for kernel development,
> to the point that practically we couldn't do without it any more, and
> it isn't merged into the kernel. It's a separate project with a
> separate life, and it is *better* for it.

Sure but the difference between "git" and kvmtool is that a significant
chuck of kvmtool development is directly related to in-kernel KVM and
device drivers. That's why I've argued from day one that tools/kvm is
'special'.

			Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists