| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Qemu-devel] Re: [Xen-devel] [PATCH 0/7] merge some xen bits into qe
Hi Ian,
Ian Jackson wrote:
People unfamiliar with the context should note that Gerd's submission
is NOT `merging some Xen bits into qemu'. The code that Gerd is
submitting is VERY SUBSTANTIALLY DIFFERENT from the code which exists
in the Xen version of qemu.
Here's how I see things:
Gerd has implemented an alternative userspace for Xen PV guests all
based on QEMU. The code is well structured and integrates into QEMU in
a nice way. On technical merits alone, I have a hard time not merging
it into QEMU.
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.
Naturally, this alternative userspace fits well for something like
Xenner which emulates a Xen PV guest in QEMU or KVM. This is also
something that I don't think Xen.org will ever bless.
Gerd has posted this series on xen-devel and there hasn't been any real
substantial feedback. He's been pretty patient about it. I think this
is somewhat misleading because I don't think there's any chance these
patches will ever be pulled into xen-unstable. And BTW, any code that
has a remote chance of being merged into QEMU eventually should be
cross-posted on qemu-devel. Developing on xen-devel and then dropping a
big pile of crud onto qemu-devel is not a viable development style. The
same is true for other QEMU forks like KVM.
All this said, I don't think we should just pull in Gerd's patches as-is
and forget about the Xen.org blessing. I want to encourage all of the
work that's being done in xen-unstable to be merged back into QEMU
upstream and that would certainly discourage this process.
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.
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.
I hope this will make everyone happy and we can stop posting this series
and arguing about it. Does anyone have any objections to this?
Regards,
Anthony Liguori
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home