From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] State of KVM bits in linux-headers Date: Thu, 12 Jan 2012 10:34:30 +0200 Message-ID: <4F0E9B16.4070502@redhat.com> References: <4F0DE028.4050707@siemens.com> <4F0DE54F.1050700@siemens.com> <4F0DE5F2.7090001@codemonkey.ws> <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@suse.de> <4F0DE7A4.5050000@siemens.com> <4F0DE867.6030303@codemonkey.ws> <59344EBA-23C4-4D25-9802-C627AAB8FFFA@suse.de> <4F0DEA28.9010700@codemonkey.ws> <4F0DEE38.6060100@codemonkey.ws> <1BB20E87-50DA-4C5F-BE42-9C553A4AA533@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Jan Kiszka , Marcelo Tosatti , qemu-devel , kvm To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60481 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752854Ab2ALIem (ORCPT ); Thu, 12 Jan 2012 03:34:42 -0500 In-Reply-To: <1BB20E87-50DA-4C5F-BE42-9C553A4AA533@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 01/11/2012 11:48 PM, Alexander Graf wrote: > > > > Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet. We can't release any qemu that depends on something not upstream. > The question again is: When do we consider something upstream? This far from a qemu release, we can consider anything in in kvm.git master (or slightly trailing that, kvm.git linux-next) as upstream. It's very rare that an ABI gets pulled out of that and not merged, and if it is, we can pull out the qemu feature. An ABI can change, but that just means we need to echo the change in qemu. As qemu gets closer to release, we'll need to look at Linus' tree instead of kvm.git. > >> > >> right? And then after about 3 months we'll have the feature available ;). > > > > You can always just get Acked-by's from the appropriate maintainers. That's just as good as going through the tree. > > So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :) Of course I can complain about my patches later. Complained-about-by: Avi Kivity But yes, if your change involves multiple subsystem, get it through the most affected subsystem and get acks from the rest. -- 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]:40738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlG7R-000755-29 for qemu-devel@nongnu.org; Thu, 12 Jan 2012 03:34:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RlG7K-0001w2-Ta for qemu-devel@nongnu.org; Thu, 12 Jan 2012 03:34:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlG7K-0001vQ-Mk for qemu-devel@nongnu.org; Thu, 12 Jan 2012 03:34:38 -0500 Message-ID: <4F0E9B16.4070502@redhat.com> Date: Thu, 12 Jan 2012 10:34:30 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F0DE028.4050707@siemens.com> <4F0DE54F.1050700@siemens.com> <4F0DE5F2.7090001@codemonkey.ws> <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@suse.de> <4F0DE7A4.5050000@siemens.com> <4F0DE867.6030303@codemonkey.ws> <59344EBA-23C4-4D25-9802-C627AAB8FFFA@suse.de> <4F0DEA28.9010700@codemonkey.ws> <4F0DEE38.6060100@codemonkey.ws> <1BB20E87-50DA-4C5F-BE42-9C553A4AA533@suse.de> In-Reply-To: <1BB20E87-50DA-4C5F-BE42-9C553A4AA533@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] State of KVM bits in linux-headers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Jan Kiszka , Marcelo Tosatti , qemu-devel , kvm On 01/11/2012 11:48 PM, Alexander Graf wrote: > > > > Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet. We can't release any qemu that depends on something not upstream. > The question again is: When do we consider something upstream? This far from a qemu release, we can consider anything in in kvm.git master (or slightly trailing that, kvm.git linux-next) as upstream. It's very rare that an ABI gets pulled out of that and not merged, and if it is, we can pull out the qemu feature. An ABI can change, but that just means we need to echo the change in qemu. As qemu gets closer to release, we'll need to look at Linus' tree instead of kvm.git. > >> > >> right? And then after about 3 months we'll have the feature available ;). > > > > You can always just get Acked-by's from the appropriate maintainers. That's just as good as going through the tree. > > So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :) Of course I can complain about my patches later. Complained-about-by: Avi Kivity But yes, if your change involves multiple subsystem, get it through the most affected subsystem and get acks from the rest. -- error compiling committee.c: too many arguments to function