Re: Xen 3.2.0 Packages

[Curt Sampson <cjs%NetBSD.org@localhost>]

On 2008-01-22 19:17 +0100 (Tue), Manuel Bouyer wrote:

> On Tue, Jan 22, 2008 at 06:34:30PM +0900, Curt Sampson wrote:
> > Is anybody working on upgrading the xentools3 and xenkernel3 packages in
> > pkgsrc for Xen 3.2.0?
> 
> I've not looked at it yet. It may require some adjustements on the OS
> side too ...

Any idea what these might be?

I built, by hand, a Xen 3.2.0 kernel, following the "instructions" in
the pkgsrc xenkernel3 Makefile, and that kernel seems to work fine
(albeit without having tested domUs yet) on a Core 2 Duo system, except
for the parallel IDE speed problem (which I will describe in a separate
post). I have a suspicion this may be true of an AMD x64 system as well;
I'll be testing this tomorrow.

Looking at what the xentools3 package provides (extra scripts, some
extra python package dependencies that aren't mentioned as necessary in
the Xen3 user's guidde list of requirements), it appears to me that it's
easier to upgrade the package than to try to build the tools straight
from the Xen sources. So that's the approach I'm going to look at.

Given the level of differences between Xen 3.1 and 3.2 (to the point
where the 3.1 tools don't work on 3.2), it seems fairly obvious to me
that we want to start including the minor version number in the package
names (at lest for xen 3), and also generated files where we can do
this. So unless anybody has any objections, I am going to start with
this:

    1. Rename xenkernel3 and xentools3 to xenkernel31 and xentools31.

    2. Change xenkernel2 and xenkernel31 to generate kernel files named
    "xen2.gz" and "xen-3.1.2.gz" (and of course similar for the debug
    kernels).

    3. Add a xenkernel32 package that generates a kernel named "xen-3.2.0.gz"

    4. Add notes to the DESCR files for xen 3 packages noting that the
    3.1 and 3.2 tools are not compatable.

This will help greatly with my project, which is to get Xen-3-anything
running ASAP on a Core 2 Duo machine (which probably means rolling back
to 3.1) and continue trying to get the AMD x64 machine to work (with a
32-bit kernel) which probably means running Xen 3.2 on it.

The next step, of course, is for someone to build the 3.2 tools. My
business partner Bryan has started having a look at this, but it's his
first go at hacking packages, and given my experience with the learning
curve on this, I wouldn't hold your breath.

cjs
-- 
Curt Sampson       <cjs%starling-software.com@localhost>        +81 90 7737 
2974   
Mobile sites and software consulting: http://www.starling-software.com