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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E2CA6DE.4040900@web.de>
Date:	Mon, 25 Jul 2011 01:12:30 +0200
From:	Jan Kiszka <jan.kiszka@....de>
To:	Pekka Enberg <penberg@...nel.org>
CC:	torvalds@...ux-foundation.org, mingo@...e.hu, avi@...hat.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, gorcunov@...il.com, levinsasha928@...il.com,
	asias.hejun@...il.com, prasadjoshi124@...il.com
Subject: Re: [GIT PULL] Native Linux KVM tool for 3.1

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

Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)