On 11.01.2012, at 20:52, Anthony Liguori wrote: > On 01/11/2012 01:48 PM, Jan Kiszka wrote: >> On 2012-01-11 20:46, 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 ;). >> >> IIRC, we never had this problem with qemu-kvm - as the merges were >> coordinated with the kernel (subsystem) tree. > > Are you suggesting that kvm header updates go through uq/master? That seems reasonable to me and is certainly the least amount of change. So how about code that actually leverages the new headers? 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
