From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl40E-0001ub-3g for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:38:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rl409-0004ix-Ro for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:38:30 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:60616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl409-0004io-Ow for qemu-devel@nongnu.org; Wed, 11 Jan 2012 14:38:25 -0500 Received: by iagw33 with SMTP id w33so1826549iag.4 for ; Wed, 11 Jan 2012 11:38:24 -0800 (PST) Message-ID: <4F0DE52B.8030105@codemonkey.ws> Date: Wed, 11 Jan 2012 13:38:19 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F0DE028.4050707@siemens.com> In-Reply-To: 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: Alexander Graf Cc: Jan Kiszka , qemu-devel , kvm On 01/11/2012 01:32 PM, Alexander Graf wrote: > > On 11.01.2012, at 20:16, Jan Kiszka wrote: > >> Hi, >> >> I'm a bit unhappy about the current state of our supposed to be >> automatically sync'ed linux-headers directory in qemu. It has been >> updated several times against undefined kernel trees, means against >> neither a released version nor kvm.git. Now, if I run an update against >> kvm.git + some local change, I get a churn of removals. Same will happen >> when that local change ever goes upstream before the other stuff got >> finally committed. > > Yes, call me even more unhappy about it :(. May I suggest the following: 1) Have the header syncing script take a commit hash that's stored in git. Make script ensure that this has is in Linus' tree. 2) Maintain a patch on top of Linus' tree in qemu.git that the script would apply before actually syncing header files. That let's us track how we're differing from upstream in a more reliable fashion. >> Alex, it looks to me like this is mostly PPC stuff. Can you comment on >> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a >> year ago but is not in any Linux release around. Fishy... > > Ok, here's my workflow: > > * KVM: receive patches on the ML > * KVM: wait for reviews, review myself > * KVM: send out a pull request > -- this is the point in time where I assume the ABI can be considered stable -- > * QEMU: run update on the headers, because in a perfect world things should hit kvm.git any day > * KVM: pull request gets reviews causing not-pulls or abi changes and lots of churn because i need forever to pullreq again ;) > > I guess you see the problem. Hence I haven't pushed any kernel header updates since I realized how badly broken that process was. However even the stuff that's in qemu.git now hasn't managed to get upstream yet. I don't think it's a broken process. I think you made a reasonable set of assumptions. I think it was just an exceptional circumstance. Regards, Anthony Liguori