[kvmarm] [GIT PULL v2] KVM/ARM Fixes for 3.9-rc1

Christoffer Dall cdall at cs.columbia.edu
Fri Mar 8 14:26:44 EST 2013

On Thu, Mar 7, 2013 at 7:12 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Thu, 7 Mar 2013 16:09:00 -0300, Marcelo Tosatti <mtosatti at redhat.com>
> wrote:
>> On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote:
>>> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
>>> <cdall at cs.columbia.edu>
>>> wrote:
>>> > On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier at arm.com>
>>> wrote:
>>> >> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
>>> >> <cdall at cs.columbia.edu>
>>> >> wrote:
>>> >>
>>> >> Hi Christoffer,
>>> >>
>>> >>>
>>> >>> Please pull these KVM/ARM fixes mostly centered around preparation
>>> >>> for
>>> >>> Marc's ARMv8 KVM work.
>>> >>
>>> >> Can we please hold on that for a while? asm-offset.c is usually a
>>> >> candidate for merge conflicts as people start pushing patches post
>>> merge
>>> >> window, and it would make sense to see what is happening in that
>>> >> space.
>>> >>
>>> > Sure, when would you see this happen exactly?
>>> Usually, by -rc5 we have a pretty good idea of what is going in. Also,
>>> putting things into -next is a good way to detect potential problems.
>>> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers
> don't
>>> follow the KVM lists.
>>>         M.
>> Mark, can you please be more verbose on the reason for this request?
> arch/arm/kernel/asm-offset.c, being an ARM core file, is often the
> location of merge conflicts. And because arch/arm sees a lot more churn
> than any other architecture, we have the policy of dealing with conflicts
> before they hit Linus.
> We usually deal with that by providing stable branches that will contain
> the "offending" patches, and on which others can base their developments.
> This is why I suggested holding on this pull request until we got a better
> view of what potential merge conflicts we get with this patches. This
> shouldn't prevent the patches from entering -next though, as this would
> help detecting the above conflicts.
So I think you need to explain me a little more carefully how the
'usually' applies in this case. This is just a pull request to the
kvm/master branch - it's not to Linus or ARM-specific. The only thing
is that we touch asm-offsets.c.

The only thing I can see that happens here is:
 - merge to kvm/master
 - kvm/master gets merged by Linus into -rcX (he fixes any merge
conflicts if present)
 - we, ARM, kvm, everyone, pull back from Linus

and that's it.

Perhaps it would be helpful if you can explain the situation we need
to avaoid and what exactly is the scenario when this breaks?

The merge conflicts in asm-offsets.c should be uber-trivial, so I'm
not sure what the big deal is.


More information about the linux-arm-kernel mailing list