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
--
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
