Re: Planning the merge of KVM/arm64

[Marc Zyngier <marc.zyngier@arm.com>]

On 04/06/13 16:30, Paolo Bonzini wrote:

Hi Paolo,

> Il 04/06/2013 16:59, Marc Zyngier ha scritto:
>>>>>> - Either I can rely on a stable branch from both KVM and
>>>>>> KVM/ARM trees on which I can base my tree for Catalin/Will
>>>>>> to pull, - Or I ask Catalin to only pull the arm64 part
>>>>>> *minus the Kconfig*, and only merge this last bit when the
>>>>>> dependencies are satisfied in Linus' tree.
>>>>>> 
>>>>>> What do you guys think?
>>>>>> 
>>>> I would think you would prefer option (1) to get the code in
>>>> cleaner. Both the KVM/next tree is stable and I can provide you
>>>> with a stable KVM/ARM tree. But I really don't feel strongly
>>>> about this.
>> That'd be my preferred choice too. Let's see what the KVM
>> maintainers' position on that.
> 
> I wonder if Linus would complain about irrelevant KVM changes in 
> Will/Catalin's pull request.  The KVM/next tree has other patches
> below the ones you need.

That's how the ARM tree is dealt with most of the time. We create stable
branches (that we know for sure are going in at the next merge window)
that are used as a base for others to base their own developments.
KVM/ARM has been merged like this, using something crazy like half a
dozen stable branches from different contributors... So far, Linus
hasn't complained.

KVM/arm64 is not that bad in that respect, but I'm inclined to follow
the same process.

> What we usually do for x86 is get an Acked-by from the other part.
> If there are no dependencies on other aarch64 core changes, it'd be
> better to go through the KVM tree.

There is a number of potential additions to the arm64 tree that may
conflict with KVM/arm64 (THP comes to my mind...).

> Otherwise separating the Kconfig change should be okay (perhaps add
> it with depends on BROKEN, and remove the dependency later?).

Could do, yes.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...