Re: [Xen-ia64-devel] the xenLinux/IA64 upstream merge and Fedora.

[Aron Griffis <aron@xxxxxx>]

Hi Stephen,

Stephen C. Tweedie wrote:  [Wed Dec 05 2007, 12:52:30PM EST]
> Hi,
> 
> On Wed, 2007-12-05 at 12:26 -0500, Aron Griffis wrote:
> 
> > >   http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
> > >   Does Fedora have any forward ported tree?
> > 
> > This question is probably best answered by Stephen.  I think what we
> > want is an x86 forward-ported tree so we can see how the generic bits
> > change.  Then it's just a matter of making arch/ia64 changes to
> > accomodate, right?
> 
> Nononono!  The entire point of our exercise is to avoid forward-porting,
> as forward-porting is becoming increasingly burdensome and error-prone
> as the upstream Linux tree diverges from the 2.6.18 xen-unstable tree.
> 
> The Linus 2.6.24 tree already has pv_ops in it, with Xen support, for
> i686.  Forward-porting the 2.6.18 tree just means trying to squeeze the
> old-style Xen hooks into a tree that already has completely different
> virtualisation hooks in it.
> 
> So our effort here is specifically NOT to forward-port the whole of Xen,
> but to use the 2.6.24 pv_ops as a starting point, and merge into it ONLY
> the selected bits from 2.6.18 that pv_ops does not yet have (such as
> dom0 support.)

Sorry, what you're saying is what I intended.  By "x86 forward-ported
tree" I meant "x86 pv_ops tree".

For ia64 there is still a question of how we'll use pv_ops.  We
already have the machine vector which provides something similar.
Yamahata-san also has a binary-patching pv_ops alternative which might
work better on ia64 than the stock pv_ops.

> > As an experiment, I started a merge of arch/ia64 to v2.6.23.
> 
> One of the main goals here is to reduce the effort of keeping a full Xen
> tree in sync with upstream (ideally, with the long-term goal of getting
> things fully merged, although that may not be completely practical for
> everything that Xen does.)  So, rather than just merging 2.6.18-xen's
> existing stuff into 2.6.23/24, we should probably be trying to follow
> what i386 did in pv_ops, and getting a pv_ops-based ia64 implementation
> to build on.  There's a good chance of getting that into the upstream
> kernel (at least for domU, which is where we're at on i686 upstream
> too), which will help the long-term maintainability no end.

Depending on how ia64 uses pv_ops, the code in arch/ia64 could look
somewhat *similar* to what we have now, albeit cleaned up, moved
around and submitted piecemeal upstream.  My forward merge was just to
see how badly it would conflict with current linux/ia64 code, not
because I was thinking that was the correct path.

> > So if xenlinux/ia64 is merged into kernel.org, would we then
> > concentrate all our kernel efforts on that tree and eventually abandon
> > linux-2.6.18-xen.hg?
> 
> Absolutely, our goal is never to have another linux-2.6.18-xen.hg-based
> tree in Fedora again --- we want to rebuilt a new tree based on what's
> upstream in 2.6.24, which will probably have to be git-based to stay
> close to upstream as efficiently as possible.
> 
> >   I know this is a rhetorical question, but
> > it seems like it would be better to concentrate on the current tree in
> > the future, rather than needing to forward port changes continuously.
> 
> If by "current tree" you mean the Linus upstream as opposed to the aging
> XenSource 2.6.18, then yes, that's exactly what we're trying to achieve
> here.

Right, that's what I meant.  Sorry for the unclear terms. :-(

Thanks,
Aron

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel