From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] State of KVM bits in linux-headers Date: Wed, 11 Jan 2012 13:52:07 -0600 Message-ID: <4F0DE867.6030303@codemonkey.ws> References: <4F0DE028.4050707@siemens.com> <4F0DE54F.1050700@siemens.com> <4F0DE5F2.7090001@codemonkey.ws> <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@suse.de> <4F0DE7A4.5050000@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , qemu-devel , kvm , Marcelo Tosatti , Avi Kivity To: Jan Kiszka Return-path: Received: from mail-tul01m020-f174.google.com ([209.85.214.174]:64838 "EHLO mail-tul01m020-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755909Ab2AKTwN (ORCPT ); Wed, 11 Jan 2012 14:52:13 -0500 Received: by obbup16 with SMTP id up16so1266809obb.19 for ; Wed, 11 Jan 2012 11:52:13 -0800 (PST) In-Reply-To: <4F0DE7A4.5050000@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/11/2012 01:48 PM, Jan Kiszka wrote: > On 2012-01-11 20:46, Alexander Graf wrote: >> >> On 11.01.2012, at 20:41, Anthony Liguori wrote: >> >>> On 01/11/2012 01:38 PM, Jan Kiszka wrote: >>>>> >>>>>> I would like to see us avoiding this in the future. Headers update >>>>>> patches should mention the source and should not be merged until the ABI >>>>>> changes actually made it at least into kvm.git. Same applies, of course, >>>>>> to the functional changes related to that ABI. Otherwise we risk quite >>>>>> some mess on everyone's side. >>>>> >>>>> I agree. >>>>> >>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel >>>>>> and also the header. Is there real free space now or will the cap >>>>>> reappear? If there should better be a placeholder, let's add it (to the >>>>>> kernel). >>>>> >>>>> I will reappear with ONE_REG semantics. >>>>> >>>> >>>> OK. >>>> >>>> Then please clean up now so that update-linux-headers.sh can be used >>>> again by "normal" developers. :) >>> >>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies. I think that's a good strategy here too. It's a little painful, but not entirely awful. >>> >>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo. >> >> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;). > > IIRC, we never had this problem with qemu-kvm - as the merges were > coordinated with the kernel (subsystem) tree. Are you suggesting that kvm header updates go through uq/master? That seems reasonable to me and is certainly the least amount of change. Regards, Anthony Liguori > > Jan >