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

[Gerd Hoffmann <kraxel@xxxxxxxxxx>]

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