From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQg3v-0000BN-1y for qemu-devel@nongnu.org; Wed, 06 Aug 2008 06:16:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQg2L-0008Ft-QV for qemu-devel@nongnu.org; Wed, 06 Aug 2008 06:16:09 -0400 Received: from [199.232.76.173] (port=51528 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQg2K-0008F9-Or for qemu-devel@nongnu.org; Wed, 06 Aug 2008 06:14:32 -0400 Received: from mx1.redhat.com ([66.187.233.31]:55083) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQg2K-00032s-1Z for qemu-devel@nongnu.org; Wed, 06 Aug 2008 06:14:32 -0400 Message-ID: <48997981.1030703@redhat.com> Date: Wed, 06 Aug 2008 12:14:25 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu References: <1217865045-10722-1-git-send-email-kraxel@redhat.com> <48973F8E.8080109@codemonkey.ws> <20080805104630.GM4478@implementation.uk.xensource.com> <489835A3.6030804@redhat.com> <20080805112935.GO4478@implementation.uk.xensource.com> <48985336.2020709@redhat.com> <20080805150328.GT4478@implementation.uk.xensource.com> <20080805154140.GV4478@implementation.uk.xensource.com> In-Reply-To: <20080805154140.GV4478@implementation.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Samuel Thibault , Gerd Hoffmann , Anthony Liguori , qemu-devel@nongnu.org, xen-devel@lists.xensource.com, Ian Jackson Samuel Thibault wrote: > Samuel Thibault, le Tue 05 Aug 2008 16:03:28 +0100, a =E9crit : >> Gerd Hoffmann, le Tue 05 Aug 2008 15:18:46 +0200, a =E9crit : >>> Samuel Thibault wrote: >>>> Then it'd probably be good to push that upstream Xen. >>> I'm cross-posting the patches to xen-devel for a reason. >> Well, cross-posting qemu patches to xen-devel is not the same as posti= ng >> xen patches to xen-devel... >=20 > Just to explain a bit more, now that I have read the patches a bit: wha= t > is there is somehow far from the xen unstable tree, at least because > of the backend driver core, and because of other 'details' (renaming, > moving). I doubt Ian will be happy to have to make the effort to merge > that in his tree and I guess he will probably just drop everything and > keep the xen-unstable version. Sure, merging stuff upstream involves alot of work short-term, you'll get the benefits long-term. pv domain support is easy, as this is largely self-contained. hvm will be even more work, because hvm support is much more invasive and on top of that the qemu interfaces will change to nicely support the various ways to run code natively instead of emulated (kqemu, kvm, xen). The rough way to merge would look like this: - drop xen_console.[ch] - drop xenfb.[ch] - drop xen_machine_pv.c - add xen.h - add xen-machine.c - add xen-backend.[ch] - add xen-console.c - add xen-framebuffer.c - wind up stuff in the Makefiles. - some global renames (domid -> xen_domid for example) as I took care to prefix global xen variables & functions with xen_. - probably some small fixups are needed ... You probably wouldn't do that before the 3.3 (4.0?) release. If you keep the xenish vl.c version the differences between upstream qemu and qemu-dm command line options and vnc handling go away. The you can gradually move qemu-dm to be more upstream-ish while also updating xend accordingly. Note that qemu-dm has a few optimizations in the qemu display code to avoid unneeded work. I'd suggest to submit them upstream. The we can enable the bits in xen-framebuffer.c which make use of them. DisplayState->idle for example. cheers, Gerd --=20 http://kraxel.fedorapeople.org/xenner/