| |
|
 |
|
 |
|
|
|
| |
|
|
xen-merge
RE: [Xen-merge] xen-merge mailing list
> > 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 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.
> Now if we had an idea on what shape would be best for merging
> things into the xen-unstable tree, we could work backwards
> from there to come up with the kind of changes to generate.
>
> Of course, we may still come up with the conclusion that we
> want the mercurial trees, but at least we'll know why ;)
Ian
_______________________________________________
Xen-merge mailing list
Xen-merge@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-merge
|
|
|
| |
|
Home