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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

On 2011-07-24 22:37, Pekka Enberg wrote:
> Hi Linus,
> 
> Please consider pulling from
> 
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
> kvm-tool-for-linus
> 
> to merge the Native Linux KVM tool to Linux 3.1.
> 
> [ The changes to 9p headers were already merged but show up in the pull
> request. ]
> 
> The goal of this tool is to provide a clean, from-scratch, lightweight
> KVM host
> tool implementation that can boot Linux guest images with no BIOS
> dependencies
> and with only the minimal amount of legacy device emulation. The primary
> focus
> of the tool is to Linux but there are already people on working on
> supporting
> GRUB and other operating systems.
> 
> We want the tool to be part of Linux kernel source tree because we
> believe that
> ‘perf’ clearly showed the benefits of a single repository for both
> kernel and
> userspace components. See Ingo Molnar’s email that started the project for
> details:
> 
>   http://thread.gmane.org/gmane.linux.kernel/962051/focus=962620

I've read several times now that developing in a single tree leads to
better results. Can you provide some example from the QEMU/KVM projects
where the split is preventing innovation, optimizations, or some other
kind of progress?

Let's assume this gets merged. What will change for people working on
generic or x86 KVM features? Will they sooner or later be asked to
provide corresponding bits also for the tools folder? Having worked on
two userlands over the past years (QEMU and qemu-kvm), still
contributing to finally unify them, I'm wondering if this will end up
repeating the painful history.

That said, I definitely appreciate the bug fixes as well as code and
documentation improvements for KVM that originate from this effort! I'm
just not convinced that writing a new userland and merging it into the
kernel is the most efficient way to achieve that.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]