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

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

[Ian Jackson]

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.

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

[Anthony Liguori]

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.
>
>
>   

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

[Blue Swirl]

On 8/11/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> 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.

What about nodisk_ok? That should not make merging too hard.

Re: [PATCH 00/11] merge some xen bits into qemu

[Blue Swirl]

On 8/11/08, Anthony Liguori <anthony@codemonkey.ws> wrote:
> 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.

What about nodisk_ok? That should not make merging too hard.

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

[Ian Jackson]

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.

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

[Gerd Hoffmann]

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/

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

[Samuel Thibault]

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

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

[Samuel Thibault]

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

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

[Gerd Hoffmann]

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/

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

[Gerd Hoffmann]

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/

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

[Samuel Thibault]

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

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

[Samuel Thibault]

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

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

[Gerd Hoffmann]

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/

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

[Gerd Hoffmann]

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/