This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH] linux/netback: save interrupt state in add_to_ne

On Tue, 2010-09-14 at 10:26 +0100, Jan Beulich wrote:
> >>> On 14.09.10 at 11:12, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > On Mon, 2010-09-13 at 15:38 +0100, Jan Beulich wrote:
> >> >>> On 13.09.10 at 16:14, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> >> > Which tree are you intending for this (and the other kernel patches you
> >> > sent recently) to be applied to?
> >> 
> >> Oh, right, for this one it isn't obvious from the paths. They're all for
> >> the 2.6.18 one, in an attempt to at least avoid carrying patches of
> >> our own where they can easily be made apply to what we derive
> >> our tree from.
> > 
> > Ah, I hadn't realised anyone still cared about updating the 2.6.18-xen
> > tree so it didn't occur to me.
> How would we (and even you) not care? There's now newer tree
> available that can serve as an input (in some cases we can pull
> fixes from the pv-ops tree, but that's not the normal case). Even
> your XCP tree (indirectly) depends on the 2.6.18 one, as you
> derive it from ours (and hence we can't reasonably use it as a
> replacement source).

Yes, I hadn't considered this until now, I see the dilemma.

I don't think any one really wants to perpetuate the classic-Xen port
any further by creating a new upstream linux-2.6.32-xen.hg (although I
suppose we could if there was demand) so stashing patches like this in
the linux-2.6.18-xen.hg tree makes sense.

>  With pv-ops continuing to be (somewhat?)
> experimental, I have always been wishing we could get to a point
> where we'd have a more modern baseline tree, but I don't really
> have any hope for such.
> Nor can I foresee when the pv-ops tree will be reliable enough
> and sufficiently functionally complete (without hacks that in
> some cases I think are worse than those in the 2.6.18 tree) to
> be used as the basis of an enterprise Dom0 (which is the
> criteria that could make us finally do the long hoped for switch).

I guess there is a certain amount of chicken and egg there and I also
suppose nobody really wants to be the guinea pig ;-)

FWIW I hope that XCP can make the switch before too long and that
XenServer will be able to follow, perhaps in the next major release.


Xen-devel mailing list