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

Pekka Enberg
2011-07-25T07:37:57Z

Hi Jan,

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