[Fedora-xen] New kernel-xen in rawhide

[Mark McLoughlin]

On Fri, 2008-07-18 at 19:10 +0100, Daniel P. Berrange wrote:
> On Fri, Jul 18, 2008 at 05:26:58PM +0100, Mark McLoughlin wrote:
> > Hi,
> > 	Just a heads up that I'm pushing a new 2.6.27 based kernel-xen to
> > rawhide. This includes Jeremy Fitzhardinge's xen-64bit tree[1] in place
> > of Eduardo's xen-pvops-64.git tree.
> > 
> > 	Basically, Jeremy has half of the 64 bit Xen work merged for 2.6.27
> > already and the other half is queued up, hopefully to be included before
> > the merge window ends. If we can get that stuff some testing, perhaps it
> > might help the cause of getting it merged.
> > 
> > 	This is all irrelevant if the build fails, of course :-)
> 
> Seems to have succeeded, so how about putting it into the real kernel
> RPM directly, and finally kill kernel-xen as an RPM :-)

Yes, I'd very much like to make that happen soon.

There are two considerations, though:

  1) The second half of the xen x86_64 DomU work has not yet been 
     merged upstream. It's a fairly big patch:

       49 files changed, 2344 insertions(+), 913 deletions(-)

     so, if it doesn't get merged, it's possible it's easier to maintain
     that patch in a separate kernel-xen RPM. It's also questionable as 
     to whether the stock kernel RPM maintainers would be willing to 
     carry such a big patch.

     The 2.6.27 merge window is still open, though, so hopefully Ingo
     will push it up to Linus before it closes and this point will be 
     moot.

  2) For the same reasons, if we kill the separate kernel-xen RPM, that
     restricts our ability to pull in a work-in-progress Dom0 tree in
     future. I expect if we do kill kernel-xen, we won't see Dom0 in 
     Fedora until it's fully upstream.

     Since so little progress is being made currently on the Dom0 
     front, though, I don't think this is a good reason to hold off on 
     merging the RPMs.

So, my plan is to push ahead with killing off the separate RPM if the
rest of x86_64 DomU gets merged. If it doesn't, then we'll need to take
a closer look at how invasive the patch is and discuss it with the core
kernel RPM maintainers.

Cheers,
Mark.