Chris Wright wrote: [Tue Jun 27 2006, 05:34:10PM EDT]
> This should already be in tip-xen on xenbits (thanks to your patch).
>
> This should already be this way in tip-xen on xenbits, that's how I
> did the merge.
Right, these patches are not the issue. The issue is that Juan's
patch is derived from one tree while the hypervisor snapshot is taken
from another. The result is a hypervisor/kernel pair that have
a proximity window of 2 weeks or so, but should be matched if possible
to guarantee compatibility.
Generally it shouldn't be an issue, but there was a compatibility
break in ia64 recently, and the current fedora hypervisor snapshot is
on one side of the line, while the xenlinux patch is on the other.
IMHO the easiest way to avoid potential incompatibility on any
architecture is to make sure they both source from the same
xen-unstable changeset. That calls for either
- Juan to handle the linux-2.6.tip-xen tree, or
- closer synchronization between you and Juan, or
- Juan to be able to snapshot the hypervisor using the same
xen-unstable changeset used in linux-2.6.tip-xen at any time.
Maybe the last one would be easiest? Is it possible to
programmatically determine from the perspective of linux-2.6.tip-xen
the related xen-unstable changeset?
> Hmm, this one is missing, and it's not in xen-unstable sparse tree
> either, so I can see why it's not picked up.
I think it's in xen-ia64-unstable.
This is a different issue, and not one for which I have any
suggestions. The latency between xen-ia64-unstable and fedora is
unavoidably long, due to the chain: xen-ia64-unstable -> xen-unstable
-> linux-2.6.tip-xen -> Juan -> kernel.rpm. It's easy for upstream
patches to be held up on that route. For that reason, I think it's
likely an ia64 fixup patch will often be needed in kernel.rpm,
especially while xen-ia64 is seeing so much work.
Thakns,
Aron
|
