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