qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test ker


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels
Date: Sun, 06 Nov 2011 11:08:10 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 11/06/2011 10:50 AM, Avi Kivity wrote:
On 11/06/2011 06:35 PM, Pekka Enberg wrote:
The difference here is that although I feel Alex's script is a
pointless project, I'm in no way opposed to merging it in the tree if
people use it and it solves their problem. Some people seem to be
violently opposed to merging the KVM tool and I'm having difficult
time understanding why that is.

One of the reasons is that if it is merge, anyone with a #include
<linux/foo.h>  will line up for the next merge window, wanting in.  The
other is that anything in the Linux source tree might gain an unfair
advantage over out-of-tree projects (at least that's how I read Jan's
comment).

Well, having gone through the process of getting something included so
far, I'm not at all worried that there's going to be a huge queue of
"#include<linux/foo.h>" projects if we get in...

What kind of unfair advantage are you referring to? I've specifically
said that the only way for KVM tool to become a reference
implementation would be that the KVM maintainers take the tool through
their tree. As that's not going to happen, I don't see what the
problem would be.

I'm not personally worried about it either (though in fact a *minimal*
reference implementation might not be a bad idea).  There's the risk of
getting informed in-depth press reviews ("Linux KVM Takes A Step Back
 From Running Windows Guests"), or of unfairly drawing developers away
from competing projects.

I don't think that's really a concern. Competition is a good thing. QEMU is a large code base that a lot of people rely upon. It's hard to take big risks in a project like QEMU because the consequences are too high.

OTOH, a project like KVM tool can take a lot of risks. They've attempted a very different command line syntax and they've put a lot of work into making virtio-9p a main part of the interface.

If it turns out that these things end up working out well for them, then it becomes something we can copy in QEMU. If not, then we didn't go through the train wreck of totally changing CLI syntax only to find it was the wrong syntax.

I'm quite happy with KVM tool and hope they continue working on it. My only real wish is that they wouldn't copy QEMU so much and would try bolder things that are fundamentally different from QEMU.

Regards,

Anthony Liguori






reply via email to

[Prev in Thread] Current Thread [Next in Thread]