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 :(. > 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 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. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
