* Aron Griffis (aron@xxxxxx) wrote:
> 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.
This is difficult to track unless we get some actual heads up for
interface breakage. For x86 32/86, these things get caught since it's
where the bulk of the testing is done.
> 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?
The flow looks like this:
xen-unstable (sparse tree cherry picks) -> linux-2.6-xen -> linux-2.6.tip-xen
That first step records the xen-unstable cset number as part of the commit
message. So when it hits linux-2.6.tip-xen that info is preserved, and
can be culled programtically. Syncing the hv to that cset is not enough
to guarantee compatibility, but should be pretty darn likely to work ;)
The fedora side has additional changes which shouldn't be mixed with a
pristine linux-2.6.tip-xen.
thanks,
-chris
|
