Mailing List Archive

[Xen-merge] xen subarch
Folks,

We need to revitalise the efforts to get the xen patch into a form that
we'd be happy submitting to Andrew/Linus. I know everyone's very busy,
but if we can have a 'big push' over the next couple weeks we might be
able to get some useful stuff into 2.6.15.

To try and kick things off, we've created a Linux mercurial repo which
has xen as a subarch of i386 and x86_64 :
http://xenbits.xensource.com/linux-2.6-xen.hg

This is based on Chris Wright's patches, but doesn't go quite as far as
we haven't attempted to merge the include files yet. It's based on the
latest -unstable arch xen patches, and on Linux 2.6.12. We plan to
upgrade to 2.6.13 tomorrow, and then 2.6.14 as soon as it's released
(we'll actually start on the git snapshots).

The plan is that the above tree will always contain the latest version
of subarch xen, and be based off the latest Linus release. [*]

For the subarch clean up work we have another tree
http://xenbits.xensource.com/linux-2.6-merge.hg that is parented from
the above tree (so we can pull through pathches from the stable xen
subarch tree). The intention is to keep this tree up to date with the
latest Linus git snapshot, and for it to be the focus of efforts to
cleanup the subarch and remove duplication between files.

So, who's up for wading in and getting started with the cleanup? Who
can help us keep the tree up todate with Linus'?

Send me an ssh2 key if you want push rights to this tree, or otherwise
want other trees created as staging areas. We might as well use the
xen-merge for patch review and discussion. [Visit
lists.xensource.com/xen-merge to subscribe ]

Thanks for your support!

Ian

[*] we're not going to delete the sparse tree in the Xen repo right
away, as its useful for tying the xen and linux patch versions together
which makes debugging easier. What we'll do is rearrange the current
sparse tree to be an exact copy of the files in linux-2.6-xen.hg and
keep the two in sync mechanically.











_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
Re: [Xen-merge] xen subarch [ In reply to ]
On Mon, 10 Oct 2005, Ian Pratt wrote:

> To try and kick things off, we've created a Linux mercurial repo which
> has xen as a subarch of i386 and x86_64 :
> http://xenbits.xensource.com/linux-2.6-xen.hg

$ hg clone http://xenbits.xensource.com/linux-2.6-merge.hg
requesting all changes
abort: HTTP Error 404: Not Found

> So, who's up for wading in and getting started with the cleanup? Who
> can help us keep the tree up todate with Linus'?

I'm interested, and I can probably get a few other people
here interested too...

> Send me an ssh2 key if you want push rights to this tree, or otherwise
> want other trees created as staging areas. We might as well use the
> xen-merge for patch review and discussion.

It would probably be a good idea if all patches (except merges
from Linus) would get reviewed. OTOH, having review after the
fact on a changelog mailing list would probably work too.

--
All Rights Reversed

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
RE: [Xen-merge] xen subarch [ In reply to ]
> > To try and kick things off, we've created a Linux mercurial
> repo which
> > has xen as a subarch of i386 and x86_64 :
> > http://xenbits.xensource.com/linux-2.6-xen.hg
>
> $ hg clone http://xenbits.xensource.com/linux-2.6-merge.hg
> requesting all changes
> abort: HTTP Error 404: Not Found

Sorry, the two trees are:
http://xenbits.xensource.com/linux-2.6-xen.hg (latest stable)
http://xenbits.xensource.com/ext/linux-2.6-merge.hg (bleeding edge)

> > So, who's up for wading in and getting started with the
> cleanup? Who
> > can help us keep the tree up todate with Linus'?
>
> I'm interested, and I can probably get a few other people
> here interested too...

Excellent!

> > Send me an ssh2 key if you want push rights to this tree,
> or otherwise
> > want other trees created as staging areas. We might as well use the
> > xen-merge for patch review and discussion.
>
> It would probably be a good idea if all patches (except
> merges from Linus) would get reviewed. OTOH, having review
> after the fact on a changelog mailing list would probably work too.

Yep, the changelog deamon would require need some reworking to look new
csets up in a reference Linus tree to see whether they came from Linus
or not...

Ian

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
RE: [Xen-merge] xen subarch [ In reply to ]
On Mon, 10 Oct 2005, Ian Pratt wrote:

> Sorry, the two trees are:
> http://xenbits.xensource.com/linux-2.6-xen.hg (latest stable)
> http://xenbits.xensource.com/ext/linux-2.6-merge.hg (bleeding edge)

Arjan pointed out a big problem with trees like this: they
contain all changes in one big tree, while Linus prefers
smaller, individually digestible chunks.

I wonder if it would make more sense to maintain all of
Xenolinux as a big quilt patchset ?

It may make Xenolinux maintenance a little bit harder, but
it should make it a lot easier to merge things upstream.

No, I don't know whether this would actually improve things;
this is just something to think about...

--
All Rights Reversed

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
Re: [Xen-merge] xen subarch [ In reply to ]
* Rik van Riel (riel@redhat.com) wrote:
> On Mon, 10 Oct 2005, Ian Pratt wrote:
>
> > Sorry, the two trees are:
> > http://xenbits.xensource.com/linux-2.6-xen.hg (latest stable)
> > http://xenbits.xensource.com/ext/linux-2.6-merge.hg (bleeding edge)
>
> Arjan pointed out a big problem with trees like this: they
> contain all changes in one big tree, while Linus prefers
> smaller, individually digestible chunks.

Sure, but this is just a tree for getting things right. It's not
something that will feed directly to Linus necessarily.

> I wonder if it would make more sense to maintain all of
> Xenolinux as a big quilt patchset ?

That's what I was doing, but it still boiled down to a series of smaller
patches for touching common code, followed by one big hunk for the new
subarch.

> It may make Xenolinux maintenance a little bit harder, but
> it should make it a lot easier to merge things upstream.

I think we'll want to break things off and push up regardless of csets
in the hg tree. IOW, there's not a 1:1 mapping between commits in this
tree and what's useful to breakout.

thanks,
-chris

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge
RE: [Xen-merge] xen subarch [ In reply to ]
> Arjan pointed out a big problem with trees like this: they
> contain all changes in one big tree, while Linus prefers
> smaller, individually digestible chunks.

I don't think we'll actually want to point Linus at this tree.

I think we'll want to break bits out of this tree into a series of
patches that get fed to Linus/Andrew. If they accept them, we'll get
them back when we do a pull & merge.

Changesets within the merge tree should be useful for helping select
patches to break out, but the initial set of patches we'll want to send
upstream will just be cleanups and not contain the xen subarch part at
all.

I'm totally open to other suggestions, though. Perhaps we should have a
directory of broken-out patches as part of the linux tree?

Ian

> I wonder if it would make more sense to maintain all of
> Xenolinux as a big quilt patchset ?
>
> It may make Xenolinux maintenance a little bit harder, but it
> should make it a lot easier to merge things upstream.
>
> No, I don't know whether this would actually improve things;
> this is just something to think about...
>
> --
> All Rights Reversed
>

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