| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 0/7] merge some xen bits into qemu
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.
Yes, as the the intro text says. You've even quoted the paragraph here:
> Gerd Hoffmann writes ("[Xen-devel] [PATCH 0/7] merge some xen bits into
> qemu"):
>> The console and framebuffer backend drivers are largely based on the
>> xen code, the other bits are rewritten from scratch. Nevertheless
>> the code should be functionally identical.
>
> I'm afraid I'm still opposed to the approach you are taking here.
>
> The correct route for Xen support for qemu is via qemu-xen-unstable,
> not directly into upstream qemu.
There are *two* patch series for a reason. The one for upstream qemu,
and the one for qemu-xen. After applying both patch sets to both threes
they are largely identical. Anthony indicated that he wants to wait for
the qemu-xen patches being accepted before merging the patches intended
for upstream qemu. So where exactly is your problem?
> If you want to generalise the backend driver machinery, which in
> qemu-xen-unstable is used only for the framebuffer, you should submit
> your generalised backend machinery on qemu-devel.
Just done.
> qemu-dm is hardly used for paravirtual domains so this is not really
> very helpful. qemu-dm is not even used at all for most PV domains.
It isn't mandatory. But every pv domain using the pv framebuffer needs
qemu-dm. It also can be used to handle the console instead of xenconsoled.
> Command-line differences are not very important in the grand scheme of
> things but they too need to come through xen-devel so that there is a
> sane transition.
As noted in the intro text the qemu-xen patch series don't change the
command line interface. I think it is easier to hash that out later
separately and not involve xend changes in this patch series.
> For the avoidance of any doubt, Gerd's machine types are for
> _emulating_ a Xen environment on a machine without a real Xen
> hypervisor.
That is one long term goal, yes. And I want the same backend code being
used for both emulation and xen support. This patchset is about xen
support only. There are no emulation bits, they will come later.
> Gerd: Why do I keep having to repeat this point ? Your messages
> always obscure it.
When submitting xen emulation patches I will clearly state that.
> So in summary: Gerd, please post your suggestions to xen-devel only
> and explain what the purpose of each patch is.
Not involving qemu-devel here is wrong. Discussing patches for upstream
qemu without involving the relevant people isn't going to work.
Each patch comes with a description of the changes.
> If their intended use is for a system with a real Xen hypervisor and
> xend, and the patches makes sense, then we will of course take them.
They are intended for a system with a Xen hypervisor.
The disk & nic backends need some windup in xend to be usable though.
> In any case, we do not want any huge upheavals in this area that are
> not dealt with appropriately through the Xen testing and release
> processes. We definitely don't want to have replacements of whole
> swathes of our existing code appear in qemu upstream!
The qemu-xen series is bisectable. You can take the patches one by one,
run them through the test setup @ XenSource and complain loudly if I
broke something.
cheers,
Gerd
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home