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

You do realize that none of your arguments touched the "why should
Linus merge the tree" question at all?

Everything you said was about how it's more convenient for you and
Ingo, not at all about why it should be better for anybody else. You
haven't bothered to even try making it an external project, so it
doesn't compile that way. You're the only one working on it, so being
convenient for you is the primary issue. Arguments like that actively
make me not want to merge it, because they are only arguments for you
continuing to work the way you have, not arguments for why the project
would make sense to merge into the main kernel repository.

So I think we should just remove this from linux-next, and be done
with the fantasy that it makes sense to merge this. You're not even
trying to convince anybody else about the merge making sense.

You might as well continue to work the way you do, and I don't mind -
but none of it argues for me merging it into the kernel. There's no
reason why kvmtool couldn't be external the way all the other
virtualization projects are.

             Linus

On Feb 9, 2013 2:01 AM, "Pekka Enberg" <penberg@...nel.org> wrote:
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > Quite frankly, that's just optimizing for the wrong case.
>
> I obviously don't agree. I'm fairly sure there wouldn't be a kvmtool
> that supports x86, PPC64, ARM, and all the virtio drivers had we not
> optimized for making development for kernel folks easy.
>
> In fact that's something Ingo pushed for pretty hard early on and we
> also worked hard just to make the code 'feel familiar' to kernel folks.
> The assumption was that if we did that, we'd see contributions from
> people who would normally not write userspace code.
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > The merged case seems to make sense for you and Ingo, and nobody else.
>
> That's hardly surprising. I'm the only person who was crazy enough to
> listen to Ingo and follow through with the damn thing. So I either have
> the same experience and perspective as Ingo does on the matter - or I'm
> just as full of 'bullshit' as he is.
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > The only thing the lock-step does is to generate the kind of
> > dependency that I ABSOLUTELY DETEST, where one version of kvmtools
> > goes along with one version of the kernel.
>
> That is simply NOT TRUE. We have never done such a thing with 'kvmtool'
> nor I have any evidence that 'perf' has done that either. I regularily
> run old versions to make sure that we stay that way.
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > So you can't have it both ways. What's so wrong with just making it a
> > separate project?
>
> Do you really think it's an option I have not considered several times?
>
> There are the immediate practical problems:
>
>   - What code should we take with us from the Linux repository. If I take
>     just tools/kvm, it won't even build.
>
>   - Where do we do our development? Right now we are using the KVM list
>     and are part of tip tree workflow. As a separate project, we need to
>     build the kind of infrastructure we already are relying on now.
>
> Then there are the long term issues:
>
>   - How do we keep up with KVM and virtio improvements?
>
>   - How do we ensure we get improvements that happened in the kernel
>     tree to our codebase for the code we share?
>
>   - How do we make it easy for future KVM and virtio developers to
>     access our code?
>
> If you want perspective on this just ask Ingo sometime how he feels
> about making tools/perf a separate project (which I have actually done).
> Much of the *practical* aspects applies to tools/kvm.
>
> And really, I'm a practical kind of guy. Why do you think I'm willing to
> bang to my head to the wall if spinning off as a separate project would
> be as simple as you seem to think it is?
>
>                         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