Re: [GIT PULL] Native Linux KVM tool for 3.1

From: Pekka Enberg
Date: Mon Jul 25 2011 - 08:36:40 EST


Hi Christoph,

On Mon, 2011-07-25 at 06:38 -0400, Christoph Hellwig wrote:
> On Mon, Jul 25, 2011 at 10:14:13AM +0200, Alexander Graf wrote:
> > So instead of thinking a bit and trying to realize that there might be a reason people don't want all their user space in the kernel tree you go ahead and start your own crusade of creating a new user space. Great. That's how I always hoped Linux would be :(.
>
> It's not Linux in general yet, it's mostly a crusade of a few with a
> political agenda.

Would you mind sharing with the rest of us who exactly those few are and
what is their political agenda? I certainly don't recognize myself or
any of the development team from your description above. And to be
completely honest, I think that's one of the single most stupid comments
I've read in this thread.

On Mon, 2011-07-25 at 06:38 -0400, Christoph Hellwig wrote:
> And another argument, calling toyvisor2 "kvm" is a really bad idea. The
> kvm binary has been used for the kvm-patched qemu binary for quite a
> while in various distros, so re-using that name will cause utter
> confusion.

I don't foresee 'utter confusion'. The code definitely wants to live in
tools/kvm so it's logical that the executable name is called 'kvm'. If
distros want to package it with a different name, they're free to do so.

> I'm happy that you guys do another independent userspace for kvm, but
> please:
>
> a) give it a useful name

I don't think toyvisor2 will do, really. I originally wanted to call the
hypervisor 'pvm' for selfish reasons because quite frankly 'penix' just
doesn't have the prestige 'linux' has. However, Ingo convinced me that
'kvm' is a good name and I agree with that.

I'm open to alternative suggestions, though.

> b) just develop it where it belongs, your own little git repository
> somewhere

I already explained why we want it in the kernel tree and what kind of
benefits we think there are. I also explained that we want to reuse and
share code with perf, for example. If you really want to argue against
merging, you need to cough up some actual disadvantages or refute the
suggested advantages.

Pekka

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