From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753301Ab1KFP4x (ORCPT ); Sun, 6 Nov 2011 10:56:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52480 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752092Ab1KFP4v (ORCPT ); Sun, 6 Nov 2011 10:56:51 -0500 Message-ID: <4EB6AE34.2000907@redhat.com> Date: Sun, 06 Nov 2011 17:56:36 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Pekka Enberg CC: Alexander Graf , Linus Torvalds , Ingo Molnar , "linux-kernel@vger.kernel.org List" , "kvm@vger.kernel.org list" , qemu-devel Developers , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Blue Swirl Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels References: <1320543320-32728-1-git-send-email-agraf@suse.de> <4EB65C5B.8070709@redhat.com> <4EB66036.4080102@redhat.com> <1320577728.1428.73.camel@jaguar> <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels Date: Sun, 06 Nov 2011 17:56:36 +0200 Message-ID: <4EB6AE34.2000907@redhat.com> References: <1320543320-32728-1-git-send-email-agraf@suse.de> <4EB65C5B.8070709@redhat.com> <4EB66036.4080102@redhat.com> <1320577728.1428.73.camel@jaguar> <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , qemu-devel Developers , Alexander Graf , Blue Swirl , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds To: Pekka Enberg Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN55W-0006Ce-Of for qemu-devel@nongnu.org; Sun, 06 Nov 2011 10:56:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RN55V-0003pb-P1 for qemu-devel@nongnu.org; Sun, 06 Nov 2011 10:56:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34630) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN55V-0003pV-F8 for qemu-devel@nongnu.org; Sun, 06 Nov 2011 10:56:49 -0500 Message-ID: <4EB6AE34.2000907@redhat.com> Date: Sun, 06 Nov 2011 17:56:36 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1320543320-32728-1-git-send-email-agraf@suse.de> <4EB65C5B.8070709@redhat.com> <4EB66036.4080102@redhat.com> <1320577728.1428.73.camel@jaguar> <4EB67486.1070105@redhat.com> <4EB67D17.7000701@redhat.com> <4EB680D9.2070706@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pekka Enberg Cc: "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , qemu-devel Developers , Alexander Graf , Blue Swirl , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds 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 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