WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [Qemu-devel] [PATCH 13/13] xen: pv domain builder.

Gerd Hoffmann writes ("Re: [Qemu-devel] [PATCH 13/13] xen: pv domain builder."):
> > Those patches are not suitable for inclusion in qemu-xen.  This is
> > because
> >   - They rename files pointlessly
> 
> You havn't looked at them in detail for a while, right?

I just visited the URL and I still saw ...

> The pointless xen_* -> xen-* renames are all gone.  Only one is left:
> Rename xenfb.c to xen_framebuffer.c for consistency with the other xen
> files.

... this.  I agree that it would be nice to have the files have nice
names.  But for the moment when all of our trees are so heavily
diverged, and development in many of the trees is proceeding apace I
think that renaming files is very harmful.

But thanks a lot for these explanations:

> Patches 02 -> 04 pull depending patches, once you've merged with
> upstream they are not needed any more and will be removed from the patch
> set.
> 
> Patches 05 -> 09 is the backend core / console / framebuffer stuff you
> are willing to take.
> 
> Patch 10 are the xen_machine_pv.c changes (upstream changeset has this
> earlier, moved here for better bisectability).
> 
> Patch 11+ are disk + nic backends.  Ignore them if you don't want them.

Obviously when faced with a 13-patch series the first of which is a
mistake, you can understand my scepticism and my reluctance to give
each individual patch the full half hour ?

I'll take a more thorough look at 02-06.  Do they in your opinion make
sense on their own in qemu-xen-unstable ?

Ian.

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