Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)

[Pekka Enberg <penberg@kernel.org>]

On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
<torvalds@linux-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@linux-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@linux-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@linux-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