xen subarch

xen subarch

[Ian Pratt]

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. 





 

Re: [Xen-merge] xen subarch

[Rik van Riel]

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

Re: [Xen-merge] xen subarch

[Andi Kleen]

On Monday 10 October 2005 16:15, Ian Pratt wrote:

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

2.6.15? That sounds very optimistic. In theory the merge window
is supposed to be two weeks after release. And I somehow doubt
all the generic reviewing can be done in that time. Later is probably 
more realistic.

Since reviewing is probably the big bottleneck anyways I would suggest
to submit what you already have for review ASAP.

-Andi

RE: [Xen-merge] xen subarch

[Ian Pratt]

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

Re: [Xen-merge] xen subarch

[John Byrne]

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

At the moment, I have spare cycles I can use to help; however, I am not
a part of the everybody that knows what to do as was mentioned on the
virtualization list a couple of weeks ago. I could definitely use some
guidance on what I can do to help.

John Byrne

RE: [Xen-merge] xen subarch

[Rik van Riel]

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

Re: [Xen-merge] xen subarch

[Chris Wright]

* 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

RE: [Xen-merge] xen subarch

[Ian Pratt]

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