| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Qemu-devel] Re: [Xen-devel] [PATCH 0/7] merge some xen bits into qe
Anthony Liguori writes ("Re: [Qemu-devel] Re: [Xen-devel] [PATCH 0/7] merge
some xen bits into qemu"):
> [stuff]
>
> It's not Xend/blktap and while you all haven't been clear on this point,
> I don't think there's any chance that Xen.org or whatever your formal
> body is will ever bless this approach.
Well, I don't think it is our (Xen.org's) role to bless it, nor is it
our role to deprecate it. Having an alternative way of doing things
is good for everyone really so from a personal point of view I would
like to see it supported.
> [procedural discussion]
>
> 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.
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 hope [the things suggested below] will make everyone happy and we
> can stop posting this series and arguing about it. Does anyone have
> any objections to this?
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.
So I apologise if I'm being overly defensive.
And I suppose you (Anthony) are right that I should not object to
qemu-devel having visibility of these proposed changes. So I
apologise for that.
> 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'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.
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).
If we could agree on this as an approach then we could spend our time
dealing with code rather than trying to do politics.
In a spirit of goodwill I'll probably have a spare hour or two
tomorrow to go through Gerd's patch series and try to experimentally
separate out the backend-separation part with my tree and review it.
I'm afraid that I probably won't manage to get that stuff into
qemu-xen-3.4 because I'm going away and have already just dumped a
huge pile of new qemu upstream stuff into qemu-xen-unstable (because I
started the merge late due to being pulled away on another project).
But I'm prepared to maintain another branch of qemu-xen-unstable if
that helps. I'll discuss this with Keir tomorrow.
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home