From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KV4EL-00043z-Bj for qemu-devel@nongnu.org; Mon, 18 Aug 2008 08:53:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KV4EJ-00043k-OP for qemu-devel@nongnu.org; Mon, 18 Aug 2008 08:53:04 -0400 Received: from [199.232.76.173] (port=45582 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KV4EJ-00043h-JV for qemu-devel@nongnu.org; Mon, 18 Aug 2008 08:53:03 -0400 Received: from smtp.eu.citrix.com ([62.200.22.115]:12766) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KV4EJ-0003u1-Ex for qemu-devel@nongnu.org; Mon, 18 Aug 2008 08:53:03 -0400 Date: Mon, 18 Aug 2008 13:53:05 +0100 From: Samuel Thibault Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu Message-ID: <20080818125304.GM4686@implementation.uk.xensource.com> References: <18592.28557.41406.258988@mariner.uk.xensource.com> <48A09BEC.2040504@redhat.com> <20080815224142.GF5198@implementation> <48A96ED4.7070604@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48A96ED4.7070604@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org Gerd Hoffmann, le Mon 18 Aug 2008 14:45:08 +0200, a écrit : > Samuel Thibault wrote: > > Well, maybe having a version of the patch that does not convert the code > > 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" ... In verson 1.5.6.3 at least there is a -b option. > > 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? 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. > > That being said, I guess we should wait for a pull in the qemu-xen tree. > > I'd prefer to not have a patch backlog with tons of unmerged stuff ... I doubt you'll be able to produce tons of stuff until that happens. Samuel