From: Gerd Hoffmann <kraxel@redhat.com>
To: Samuel Thibault <samuel.thibault@eu.citrix.com>,
Gerd Hoffmann <kraxel@redhat.com>,
qemu-devel@nongnu.org, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu
Date: Mon, 18 Aug 2008 15:29:29 +0200 [thread overview]
Message-ID: <48A97939.7080109@redhat.com> (raw)
In-Reply-To: <20080818125304.GM4686@implementation.uk.xensource.com>
Samuel Thibault wrote:
> 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.
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?
>
> 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 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.
Even right now the patch queue is uncomfortably long for my taste.
cheers,
Gerd
--
http://kraxel.fedorapeople.org/xenner/
WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: Samuel Thibault <samuel.thibault@eu.citrix.com>,
Gerd Hoffmann <kraxel@redhat.com>,
qemu-devel@nongnu.org, xen-devel@lists.xensource.com
Subject: Re: Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu
Date: Mon, 18 Aug 2008 15:29:29 +0200 [thread overview]
Message-ID: <48A97939.7080109@redhat.com> (raw)
In-Reply-To: <20080818125304.GM4686@implementation.uk.xensource.com>
Samuel Thibault wrote:
> 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.
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?
>
> 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 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.
Even right now the patch queue is uncomfortably long for my taste.
cheers,
Gerd
--
http://kraxel.fedorapeople.org/xenner/
next prev parent reply other threads:[~2008-08-18 13:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m2n.s.1KSWf2-002Qtv@chiark.greenend.org.uk>
2008-08-11 16:57 ` [Qemu-devel] [PATCH 00/11] merge some xen bits into qemu Ian Jackson
2008-08-11 17:11 ` Anthony Liguori
2008-08-11 18:55 ` Blue Swirl
2008-08-11 18:55 ` Blue Swirl
2008-08-12 10:04 ` [Qemu-devel] " Ian Jackson
2008-08-11 20:07 ` Gerd Hoffmann
2008-08-15 22:41 ` [Xen-devel] " Samuel Thibault
2008-08-15 22:41 ` Samuel Thibault
2008-08-18 12:45 ` [Xen-devel] " Gerd Hoffmann
2008-08-18 12:45 ` Gerd Hoffmann
2008-08-18 12:53 ` [Xen-devel] " Samuel Thibault
2008-08-18 12:53 ` Samuel Thibault
2008-08-18 13:29 ` Gerd Hoffmann [this message]
2008-08-18 13:29 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48A97939.7080109@redhat.com \
--to=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=samuel.thibault@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.