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

Re: [Xen-merge] xen-merge mailing list

* Ian Pratt (m+Ian.Pratt@xxxxxxxxxxxx) wrote:
>  
> > > Is it worth us setting up one or more Linux 2.6 mercurial tress on 
> > > xenbits that we can use to show each other what we're 
> > doing? Patches 
> > > for this sort of thing aren't easy to read.
> > 
> > This worries me.  Patches that are not easy to read are going 
> > to be horribly hard to merge into xen-unstable...
> 
> I imagine the patches we submit will consist of a sequence that tidy up
> i386 and x86_64 and create all the hooks we need, and then a final patch
> that actually adds the Xen support. 
>  
> The way I would propose going about doing this is to create a Linux hg
> tree that has all the re-arrangements in it with xen as a sub-arch, and
> then generate a diff that we chop up and arrange into the separate
> patches.

The chop up and diff part isn't looking too horrible.  There will be some
headaches if it takes too long and there's lots of remerging to keep up.

> The first part of the work is going to be rearranging our sparse tree to
> split arch/xen out in to drivers/xen/core and arch/{i386/x86_64}/xen.
> Patches for this step would be very messy (mostly file renames) and
> aren't worth maintaining as patches, hence the Linux hg tree. 

Yeah, in fact, I think it can be copies during interim so both sides
can continue to build.

thanks,
-chris

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