From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753779Ab1KFQvP (ORCPT ); Sun, 6 Nov 2011 11:51:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32847 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753541Ab1KFQvO (ORCPT ); Sun, 6 Nov 2011 11:51:14 -0500 Message-ID: <4EB6BAED.2030400@redhat.com> Date: Sun, 06 Nov 2011 18:50:53 +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> <4EB6AE34.2000907@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 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. -- 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]:34022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN5w8-0005Ex-Kl for qemu-devel@nongnu.org; Sun, 06 Nov 2011 11:51:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RN5w7-0002ML-Kf for qemu-devel@nongnu.org; Sun, 06 Nov 2011 11:51:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RN5w7-0002MH-Au for qemu-devel@nongnu.org; Sun, 06 Nov 2011 11:51:11 -0500 Message-ID: <4EB6BAED.2030400@redhat.com> Date: Sun, 06 Nov 2011 18:50:53 +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> <4EB6AE34.2000907@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 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. -- error compiling committee.c: too many arguments to function