Messages in this thread | | | Date | Sun, 06 Nov 2011 17:56:36 +0200 | From | Avi Kivity <> | Subject | Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels |
| |
On 11/06/2011 03:06 PM, Pekka Enberg wrote: > On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity <avi@redhat.com> wrote: > > You say that kvm-tool's scope is broader than Alex's script, therefore > > the latter is pointless. > > I'm saying that Alex's script is pointless because it's not attempting > to fix the real issues. For example, we're trying to make make it as > easy as possible to setup a guest and to be able to access guest data > from the host.
Have you tried virt-install/virt-manager?
> Alex's script is essentially just a simplified QEMU > "front end" for kernel developers.
AFAIR it was based off a random Linus remark.
> That's why I feel it's a pointless thing to do. > > On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity <avi@redhat.com> wrote: > > You accept that qemu's scope is broader than kvm-tool (and is a > > superset). That is why many people think kvm-tool is pointless. > > Sure. I think it's mostly people that are interested in non-Linux > virtualization that think the KVM tool is a pointless project. > However, some people (including myself) think the KVM tool is a more > usable and hackable tool than QEMU for Linux virtualization.
More hackable, certainly, as any 20kloc project will be compared to a 700+kloc project with a long history. More usable, I really doubt this. You take it for granted that people want to run their /boot kernels in a guest, but in fact only kernel developers (and testers) want this. The majority want the real guest kernel.
> 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).
-- error compiling committee.c: too many arguments to function
| |