From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [Qemu-devel] State of KVM bits in linux-headers Date: Thu, 12 Jan 2012 08:35:16 +0200 Message-ID: <20120112063516.GR2167@redhat.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=us-ascii Cc: Anthony Liguori , Jan Kiszka , qemu-devel , kvm To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56207 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751549Ab2ALGfY (ORCPT ); Thu, 12 Jan 2012 01:35:24 -0500 Content-Disposition: inline In-Reply-To: <7780A9ED-CF05-41D8-8521-FDAEAC984EB7@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 11, 2012 at 08:46:38PM +0100, 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 ;). > > In my recent experience with submitting Joerg's patch series that touches both kernel and tools/perf I didn't see any advantages in having them in the same repository. Yes, the repository is the same, but maintainers are different and have their own timelines and priorities. Long story short userspace part was applied almost three month after the kernel part. -- Gleb.