From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] State of KVM bits in linux-headers Date: Wed, 11 Jan 2012 20:48:52 +0100 Message-ID: <4F0DE7A4.5050000@siemens.com> References: <4F0DE028.4050707@siemens.com> <4F0DE54F.1050700@siemens.com> <4F0DE5F2.7090001@codemonkey.ws> <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , qemu-devel , kvm To: Alexander Graf Return-path: Received: from goliath.siemens.de ([192.35.17.28]:18334 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757543Ab2AKTs6 (ORCPT ); Wed, 11 Jan 2012 14:48:58 -0500 In-Reply-To: <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl4AQ-0002yo-TS for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:49:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rl4AK-0006yF-J3 for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:49:02 -0500 Received: from goliath.siemens.de ([192.35.17.28]:20599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl4AK-0006y7-9g for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:48:56 -0500 Message-ID: <4F0DE7A4.5050000@siemens.com> Date: Wed, 11 Jan 2012 20:48:52 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F0DE028.4050707@siemens.com> <4F0DE54F.1050700@siemens.com> <4F0DE5F2.7090001@codemonkey.ws> <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@suse.de> In-Reply-To: <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@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: qemu-devel , kvm 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux