From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753570Ab1KFRIP (ORCPT ); Sun, 6 Nov 2011 12:08:15 -0500 Received: from mail-yw0-f46.google.com ([209.85.213.46]:56353 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753138Ab1KFRIO (ORCPT ); Sun, 6 Nov 2011 12:08:14 -0500 Message-ID: <4EB6BEFA.6000303@codemonkey.ws> Date: Sun, 06 Nov 2011 11:08:10 -0600 From: Anthony Liguori 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 MIME-Version: 1.0 To: Avi Kivity CC: Pekka Enberg , "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 Subject: Re: [Qemu-devel] [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> <4EB6AE34.2000907@redhat.com> <4EB6BAED.2030400@redhat.com> In-Reply-To: <4EB6BAED.2030400@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 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 >>> 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" 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] KVM: Add wrapper script around QEMU to test kernels Date: Sun, 06 Nov 2011 11:08:10 -0600 Message-ID: <4EB6BEFA.6000303@codemonkey.ws> 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> <4EB6AE34.2000907@redhat.com> <4EB6BAED.2030400@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Blue Swirl , "kvm@vger.kernel.org list" , qemu-devel Developers , Alexander Graf , "linux-kernel@vger.kernel.org List" , Pekka Enberg , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds To: Avi Kivity Return-path: In-Reply-To: <4EB6BAED.2030400@redhat.com> 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 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 >>> 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" 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN6Ce-0002DJ-33 for qemu-devel@nongnu.org; Sun, 06 Nov 2011 12:08:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RN6Cd-0004SE-2J for qemu-devel@nongnu.org; Sun, 06 Nov 2011 12:08:16 -0500 Received: from mail-gy0-f173.google.com ([209.85.160.173]:40043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN6Cc-0004S6-RI for qemu-devel@nongnu.org; Sun, 06 Nov 2011 12:08:14 -0500 Received: by gyb11 with SMTP id 11so3400047gyb.4 for ; Sun, 06 Nov 2011 09:08:13 -0800 (PST) Message-ID: <4EB6BEFA.6000303@codemonkey.ws> Date: Sun, 06 Nov 2011 11:08:10 -0600 From: Anthony Liguori 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> <4EB6AE34.2000907@redhat.com> <4EB6BAED.2030400@redhat.com> In-Reply-To: <4EB6BAED.2030400@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Avi Kivity Cc: Blue Swirl , "kvm@vger.kernel.org list" , qemu-devel Developers , Alexander Graf , "linux-kernel@vger.kernel.org List" , Pekka Enberg , =?ISO-8859-1?Q?Am=E9rico_Wang?= , Ingo Molnar , Linus Torvalds 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 >>> 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" 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 >