This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into

To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu
From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Date: Mon, 18 Aug 2008 13:53:05 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, qemu-devel@xxxxxxxxxx
Delivery-date: Mon, 18 Aug 2008 05:53:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48A96ED4.7070604@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx>, qemu-devel@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
References: <m2n.s.1KSWf2-002Qtv@xxxxxxxxxxxxxxxxxxxxxx> <18592.28557.41406.258988@xxxxxxxxxxxxxxxxxxxxxxxx> <48A09BEC.2040504@xxxxxxxxxx> <20080815224142.GF5198@implementation> <48A96ED4.7070604@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
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 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.


Xen-devel mailing list