> Very very roughly, what > I was thinking was to make (and keep maintained a stack of > (in order)): > > mainline kernel + things going upstream + rest of xen > > And keep that stack working. To put it another way, we need > to keep slicing stuff off the bottom of the Xen patch and merging it. > > I don't think we have a working stack in that form at the > moment (at least not on top of any recent mainline kernel), > which is my main concern right now (can't really do much without it). > > Would be splendid if we can keep that up-to-date with every > major release, plus -rc releases if possible. I know it's a > lot of work ... Starting with 2.6.14 we're planning on maintaining the Xen subarch in a Linux hg tree, moving away from the current sparse tree. We're planning a 'big bang' changeover where we do a course grained re-organisation of the files (based on Chris Wright's work) and sync up with 2.6.14. We'll actually have two linux trees, one based on the most recent stable Linus release that xen subarch fixes/optimiations will go into, and one that closely tracks the Linux git tree that will be used for subarch merges and cleanups. We should be able to pull stuff from the former into the latter easily. We're hoping that this tree will serve as a focal point to get people collaborating on cleaning up the subarch code. Using mercurial rather than git isn't a big deal as its easy to export from one to the other and most people are more comfortable using hg. Ian
