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
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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 FoundSorry, 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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
* 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
> 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
On Oct 10, 2005, at 6:10 PM, 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)This is great news :) Even better it seems that you have caught up with 2.6.14 recently. There seems to be some inconsistency with the HG tree (I am no expert here): $ hg heads | grep changeset | wc -l 13 That seems a little big to me. Anyway, what started this is that there is at least a few important changesets in the repo that are not in the tip, I suppose all the heads that still need merging? Are you pulling from http://www.kernel.org/hg/linux-2.6/ or from git? -JX -- "I got an idea, an idea so smart my head would explode if I even began to know what I was talking about." -- Peter Griffin (Family Guy) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel