Re: [Qemu-devel] Re: [Xen-devel] [PATCH 0/7] merge some xen bits into qemu

[Gerd Hoffmann <kraxel@redhat.com>]

Ian Jackson wrote:
>> So at this point, I think we need some clarification.  Ian, if you have 
>> no intention of ever merging these patches in any form, I think you 
>> should be clear about that.
> 
> I do want to qemu upstream to support Xenner.  And as regards qemu-xen
> I do want Gerd's changes to clean up our pv fb backend.

Great.

> But I agree that I don't think it makes sense for Gerd's _other_
> backend drivers (eg, the blkback) to go into qemu-xen-unstable; I'm
> happy for them to go into qemu upstream in due course.

> I think perhaps I'm being very defensive because I see a giant merge
> doom approaching.  Gerd keeps posting his enormous patch series and my
> immediate priority is to stop it because it will make my life very
> difficult if it is just dumped in as-is.

To avoid that merge disaster I have prepared patches for both upstream
and qemu-xen, so you'll have the files I'm touching in both trees in a
(almost) identical state when it comes to the next merge.  git should
have no trouble to handle it then.

>> Gerd, I think you need to restructure your patches to do two things.  
>> The first is to never mention the name "Xen" as it's trademarked and 
>> owned by Xen.org.  There should be no confusion that this functionality 
>> is in anyway endorsed or supported by Xen.org.  The second thing is that 
>> whatever you do has to get easily out of the way of anything that's in 
>> xen-unstable. It should cause no merging pain to Ian.  It should also
>> be relatively easy to exclude from the build.  If you just keep 
>> everything as separate files as you are, then it's just a matter of not 
>> compiling them in.
> 
> That kind of approach would make me very happy.

I'm trying hard to not break qemu-xen and will continue to do so.

> I'd also obviously like to share code with Xenner where this is
> technically sensible.
>
> I think what I would really like is to be able to straight away apply
> to qemu-xen-unstable the subset of Gerd's patches which are
>   - structural improvements to the qemu-dm pv fb backend
>     including separating out the 
>   - code improvements to the above
> but excluding all of the other non-actual-Xen stuff.

That are patches 1-4 (upstream) and patches 1-5 (qemu-xen).

Patch #1 for upstream qemu is splitted into two for qemu-xen (#1 and #5)
to make the qemu-xen patch series bisectable.

The last three patches (5-7 upstream, 6-8 qemu-xen) are block backend,
net backend and config bits for these.

> When this is done and in xen-unstable and working, we can provide it
> to qemu-devel and at that point there won't be a merge problem because
> the code added in qemu upstream will be the same as that in qemu-xen.
>
> _Then_ Gerd should submit his Xenner patches to qemu-devel and I'll
> have no objection (provided as Anthony suggests they don't interfere
> with our real-Xen setups, but I doubt there will be any insoluble
> problems).

I want keep both patch series in sync exactly to avoid merge issues.
Thats why I'm posting the patches on both lists and take into account
review comments from both sides.  So when we agree on the final cut of
the code it can be merged strait into both trees.

> But I'm prepared to maintain another branch of qemu-xen-unstable if
> that helps.  I'll discuss this wih Keir tomorrow.

That will surely help as it will decouple qemu development from xen
release cycles.  I'd suggest to branch off qemu-xen-3.4 when
xen-unstable freezes for the 3.4 release.

> In terms of naming, I'm not an official representative of Xen.org or
> Citrix on this point, but I think since the name `xenner' has already
> been used to refer to the RH KVM-based Xen-emulation, it might be
> sensible to use that name to refer to Gerd's new arrangements.
> 
> So for example, having `xenner_pv' and `xenner_hvm' machine types, and
> `-xenner-vif' or whatever for Xenner's emulated backends.

The naming convention I'm using right now is prefix 'xen_' for anything
usable when running on the Xen hypervisor.  That includes code which
will be shared by xen and xenner such as the machine type.  That also
includes the block and net backends.  They *do* work on Xen, and with
some glue in xend you should be able to use them.

The xen emulation bits are prefixed with 'xenner_'.  That includes event
channel, grant table and xenstore implementations for example.  None of
these patches are submitted yet.  Right now xenner isn't a separate
compile time option.  That should be easy to add though.

cheers
  Gerd