Il 11/11/2013 16:49, Christoffer Dall ha scritto: > I don't think it would have made much sense - that patch was part of a > series that was touching mainly arch/arm/kvm/* and therefore I > included it in my pull. It would have been strange to have a > kvm-arm-next tree that included 75% of the functionality because Marc > happens to have another patch that touches arch/arm and arch/arm64 and > have two untestable trees until the merge window... Yes, I found the original series now at http://thread.gmane.org/gmane.linux.ports.arm.kernel/274722/. BTW, why did the arm/arm64 patch move from patch 1 in Marc's post to patch 4 here? Also, the description says "this also requires a patch to kvmtool so the generated DT matches the expectations of the guest (posted separately)". Does this apply to QEMU as well? If so, can you please point me to the QEMU patch? How does this patch affect guest ABI, and is guest ABI not yet considered stable for KVM ARM? Sorry for the question storm. :) >>> There would still be the case where I carry those arm/arm64 >>> patches but the arm64 changes conflict with those in Marc's tree, no? >> >> Yes, that can still happen. Conflicts are not bad, only inconsistencies >> are. > > Not sure what you mean and where we could be more consistent to make > life easier for you. You say it should always come from the same > person, but not necessary always from the same person? > > Note: I have no problem giving my ack to patches or follow any > procedure that makes it easier, but I thought these pull requests were > quite clean (albeit a bit late). The pull requests were clean and my life wasn't complicated much... On the other hand I'm trying to understand if there's something that can be improved because the conflict surprised me. Right now, in fact, it's not even entirely clear to me why ARM and ARM64 have separate maintainers. Paolo _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
