qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu
Date: Thu, 7 Aug 2008 18:06:07 +0300

On 8/7/08, Gerd Hoffmann <address@hidden> wrote:
> Samuel Thibault wrote:
>  > Samuel Thibault, le Wed 06 Aug 2008 15:25:26 +0100, a écrit :
>  >> Pushing the cleaning changes to Xen first can be done and would entail
>  >> much easier to tackle breakage, and the merge back from qemu would then
>  >> be trivial, why not doing so?
>  >
>  > You didn't answer that part.  Really, my only concern is about having
>  > things tested.  Isn't it possible for instance to just merge the backend
>  > core (and console/xenfb updates) in Ian's tree first for a start?
>
>
> http://kraxel.fedorapeople.org/patches/qemu-xen/
>
>  I didn't touch the build system, it is even more scary than the qemu one
>  alone, I just set CONFIG_XEN unconditionally.
>
>  I also largely left vl.c as-is, so xend shouldn't need any changes.  The
>  -domid switch sets an additional (redundant) variable, to keep the
>  amount of changes as small as possible for now.  Also -name and
>  -domain-name are aliased, both set qemu_name and domain_name.

0004-xenpv-groundwork.patch

You dropped nodisk_ok support from vl.c.

0005-xen-backend-core.patch

container_of could go to osdep.h.

0006-xen-console-backend.patch

Not your fault, but a lot of places (at least ps2.c and
slavio_serial.c) define some kind of ring buffers. Maybe these could
be consolidated some time.

0007-xen-framebuffer-backend.patch

After you optimized scancode2linux[], it looks like
atkbd_set2_keycode[] and atkbd_unxlate_table[] are not needed.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]