[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E2DB4ED.4070505@web.de>
Date: Mon, 25 Jul 2011 20:24:45 +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-25 09:37, Pekka Enberg wrote:
> 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.
Mmh, you can solve problems you do not even need to know about, just by
merging them into the kernel? Wait, will send you some more! :)
>
> 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.
Tracing&profiling are important topics, but in the end just small pieces
of the virtualization problem space. If that was the strongest reason,
it would be like asking gdb guys to merge qemu because it contains a
gdbserver.
Anyway. Thanks for all the fish! Found nothing new, not much concrete,
but many really entertaining answers. So why not repeat this on the next
merge window?
Jan
Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)
Powered by blists - more mailing lists