[lkml]   [2011]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 <> 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 <> 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

    error compiling committee.c: too many arguments to function

     \ /
      Last update: 2011-11-06 16:59    [W:0.021 / U:0.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site