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

Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits into
qemu"):
> Comments?
Please do not apply these patches.  They will make my life very
difficult.

If Gerd wants to rewrite the Xen/qemu support he should come to
xen-devel and submit his patches there.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Jackson wrote:
> Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits
into qemu"):
>   
>> Comments?
>>     
>
> Please do not apply these patches.  They will make my life very
> difficult.
>   
As I''ve said before, I won''t apply these patches until
there''s agreement
that this is the right approach for QEMU and upstream Xen so no worries 
there.
> If Gerd wants to rewrite the Xen/qemu support he should come to
> xen-devel and submit his patches there.
>   
Actually, I think Gerd is taking the right approach.  How Xen (and KVM 
for that matter) integrates with QEMU is something that ought to be 
discussed in both communities.  That will make the long term merge 
prospects easier.  Working things out on xen-devel doesn''t necessarily 
mean you''re any closer to getting into QEMU if qemu-devel has been left
out of the discussion.

Regards,

Anthony Liguori
> Ian.
>
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Jackson wrote:
> Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen bits
into qemu"):
>> Comments?
> 
> Please do not apply these patches.  They will make my life very
> difficult.
Go to http://kraxel.fedorapeople.org/patches/qemu-xen/.  Apply the
patches to your tree.  Run them through the XenSource regression
testing.  Complain if I broke something.  It can''t be much easier than
that for you.
> If Gerd wants to rewrite the Xen/qemu support he should come to
> xen-devel and submit his patches there.
Huh?  Patches are posted to xen-devel too.

Puzzled,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Blue Swirl writes ("Re: [Qemu-devel] [PATCH 00/11] merge some xen bits into
qemu"):
> On 8/11/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> >  As I''ve said before, I won''t apply these patches
until there''s agreement
> > that this is the right approach for QEMU and upstream Xen so no
worries
> > there.
> 
> What about nodisk_ok? That should not make merging too hard.
Sorry, yes.  That is a good change.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Gerd Hoffmann, le Mon 11 Aug 2008 22:07:08 +0200, a écrit
:
> Ian Jackson wrote:
> > Gerd Hoffmann writes ("[Qemu-devel] [PATCH 00/11] merge some xen
bits into qemu"):
> >> Comments?
> > 
> > Please do not apply these patches.  They will make my life very
> > difficult.
> 
> Go to http://kraxel.fedorapeople.org/patches/qemu-xen/.  Apply the
> patches to your tree.  Run them through the XenSource regression
> testing.  Complain if I broke something.  It can''t be much easier
than
> that for you.
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.

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.

That being said, I guess we should wait for a pull in the qemu-xen tree.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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" ...
> 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?  Upstream xen_machine_pv.c will in the
future also have some bits to handle xen emulation which will never be
actually used when running on the xen hypervisor.  You don''t really
need
that.  But I think using the same source code it is a good idea
nevertheless, it will be less maintainance work long-term.
> 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 ...

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel