From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl43M-0005vW-CT for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:41:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rl43L-0005no-86 for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:41:44 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:49921) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl43L-0005nk-4j for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:41:43 -0500 Received: by ggnk1 with SMTP id k1so682670ggn.4 for ; Wed, 11 Jan 2012 11:41:42 -0800 (PST) Message-ID: <4F0DE5F2.7090001@codemonkey.ws> Date: Wed, 11 Jan 2012 13:41:38 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F0DE028.4050707@siemens.com> <4F0DE54F.1050700@siemens.com> In-Reply-To: <4F0DE54F.1050700@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Jan Kiszka Cc: Alexander Graf , kvm , qemu-devel 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. Regards, Anthony Liguori > > Jan >