From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KV4ni-0008Ps-Ng for qemu-devel@nongnu.org; Mon, 18 Aug 2008 09:29:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KV4nh-0008PE-TQ for qemu-devel@nongnu.org; Mon, 18 Aug 2008 09:29:38 -0400 Received: from [199.232.76.173] (port=45788 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KV4nh-0008P3-Ip for qemu-devel@nongnu.org; Mon, 18 Aug 2008 09:29:37 -0400 Received: from mx1.redhat.com ([66.187.233.31]:39922) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KV4nh-0006QD-4z for qemu-devel@nongnu.org; Mon, 18 Aug 2008 09:29:37 -0400 Message-ID: <48A97939.7080109@redhat.com> Date: Mon, 18 Aug 2008 15:29:29 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu References: <18592.28557.41406.258988@mariner.uk.xensource.com> <48A09BEC.2040504@redhat.com> <20080815224142.GF5198@implementation> <48A96ED4.7070604@redhat.com> <20080818125304.GM4686@implementation.uk.xensource.com> In-Reply-To: <20080818125304.GM4686@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 , qemu-devel@nongnu.org, xen-devel@lists.xensource.com Samuel Thibault wrote: > Gerd Hoffmann, le Mon 18 Aug 2008 14:45:08 +0200, a =E9crit : >> Samuel Thibault wrote: >>> Well, maybe having a version of the patch that does not convert the c= ode >>> into the qemu identation would help a lot for on-list review. >> Hmm, dunno how to do that best, git-format-patch seems to lack an >> equivalent of "diff -b" ... >=20 > In verson 1.5.6.3 at least there is a -b option. Ok, next respin will have version with that turned on for review. >>> Also, would it be possible to just have the backend core and >>> console+framebuffer patches alone? I don't see why we would need to >>> change xen_machine_pv.c at all. >> To stay closer to upstream? >=20 > To limit the amount of changes involved at a time. If something breaks= , > it's easier to know simply from testing a few changesets whether that's > because of this or that. Hmm, that calls more for a patch reordering in the xen patch series to make it more bisect-friendly (i.e. first put in the new backend drivers, then update xen_machine_pv.c). Right now each step single step builds, but there are a few inbetween which are not fully functional due to old backends being turned off and new ones not patched in yet ... >>> That being said, I guess we should wait for a pull in the qemu-xen tr= ee. >> I'd prefer to not have a patch backlog with tons of unmerged stuff ... >=20 > I doubt you'll be able to produce tons of stuff until that happens. Even right now the patch queue is uncomfortably long for my taste. cheers, Gerd --=20 http://kraxel.fedorapeople.org/xenner/