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]

Date:	Mon, 25 Jul 2011 10:37:50 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Jan Kiszka <jan.kiszka@....de>
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

Hi Jan,

On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka <jan.kiszka@....de> wrote:
> 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?

I really don't follow the Qemu project well enough to comment on what
your biggest pain points are there.

As for tools/kvm, it's pretty obvious by now that we want tighter
integration with perf and the tracing facilities (and share code!),
for example so for us merging to mainline is important.

On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka <jan.kiszka@....de> wrote:
> 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.

I'm not a KVM maintainer so I really don't know how tools/kvm will
change any of the above things. I'm certainly not in a position to
*require* anyone to update tools/kvm when they add new KVM features
but it'd sure be great.

On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka <jan.kiszka@....de> wrote:
> 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.

Just to make this crystal clear for everyone: if it weren't for
tools/kvm, I wouldn't be hacking on KVM at all. I've looked at Qemu in
the past (and a lot recently!) and I simply don't see myself
contributing to it, sorry. So 'most efficient' or not, I think
tools/kvm is a net win for Linux and KVM in general.

                        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/