I think it's a good idea for the Xen build system not to include a
dom0 kernel. However, it's not very clear to a newcomer how to
actually get a kernel. The xen.org download page has no links at all
to anything kernel-related. There is a page on the wiki:
http://wiki.xensource.com/xenwiki/XenDom0Kernels
However, the list is gigantic -- extremely intimidating. And there's
no generic version of the "classic" kernel; they're all branded XCP,
XCI, Novell, &c.
I think the Right Thing to do (given an ideal world), until pvops dom0
gets sufficiently upstreamed, is for xen.org to maintain two stable
releases: a reasonably stable pvops branch for the more adventurous,
and a classic xen port for the more conservative.
However, I don't have the time to do that. If we could find a
volunteer, I'm sure the community would be eternally grateful. :-)
-George
On Fri, Sep 10, 2010 at 11:09 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@xxxxxxxxxx>
> # Date 1284113350 -3600
> # Node ID 635270fe858be62c02ec2bf2cacd5fc7e2492a36
> # Parent ef7166e5640fd50c3041435f9233e3abcf12f698
> disable kernel build in Xen build system.
>
> Cloning and building a kernel as part of the Xen distribution
> implicitly advises that this kernel is the best kernel for all users
> and many users appear to be under this impression, even though there
> is no fundamental coupling between the Xen distribution and a
> particular domain 0 kernel.
>
> There are several choices available for domain 0 kernel, as well as
> other user specific variations in requirements e.g. for kernel
> configurations. It's not clear that whatever the xen build system
> happens to produce (which is really tailored to the needs of the
> automated build system) is best for anybody.
>
> Coupling the kernel build with the Xen build has proved problematic
> for stable Xen releases as it implicitly blesses the particular kernel
> (at a particular point in time) as a constituent part of the Xen
> release, while in reality the OS kernels are separate entities with
> their own release cycles which may or may not coincide with the
> maintenance of Xen stable branches.
>
> Therefore disable the building of a kernel as part of the Xen
> distribution by default and instead direct users to use an OS
> distribution provided kernel (properly packaged with security updates
> via the normal distribution mechanisms etc) where possible and give
> pointers to suitable resources providing guidance for cases where it
> is not.
>
> This decouples the implicit advice as to the best kernel at any moment
> from Xen's own release cycle and removes the implicit suggestion that
> only particular domain 0 kernel will do.
>
> The actual infrastructure is left in place since the automated test
> system (currently) relies on it (but always asks for the specific
> kernel variant it wants for a particular test).
>
> (I also tried to remove Linux-isms from the README's Quick start
> guide. In particular I'm not sure what was supposedly Linux specific
> about steps 3 and 4 therefore I have removed the suggestion that they
> are.)
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>
> diff -r ef7166e5640f -r 635270fe858b README
> --- a/README Fri Sep 10 09:55:19 2010 +0100
> +++ b/README Fri Sep 10 11:09:10 2010 +0100
> @@ -37,7 +37,7 @@ First, there are a number of prerequisit
> First, there are a number of prerequisites for building a Xen source
> release. Make sure you have all the following installed, either by
> visiting the project webpage or installing a pre-built package
> -provided by your Linux distributor:
> +provided by your OS distributor:
> * GCC v3.4 or later
> * GNU Make
> * GNU Binutils
> @@ -51,13 +51,19 @@ provided by your Linux distributor:
> * hotplug or udev
> * GNU bison and GNU flex
>
> +Second, you need to acquire a suitable kernel for use in domain 0. If
> +possible you should use a kernel provided by your OS distributor. If
> +no suitable kernel is available from your OS distributor then refer to
> +http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
> +suitable kernels to use.
> +
> [NB. Unless noted otherwise, all the following steps should be
> performed with root privileges.]
>
> 1. Download and untar the source tarball file. This will be a
> file named xen-unstable-src.tgz, or xen-$version-src.tgz.
> You can also pull the current version from the mercurial
> - repository at http://xenbits.xensource.com/
> + repository at http://xenbits.xen.org/
>
> # tar xzf xen-unstable-src.tgz
>
> @@ -68,42 +74,23 @@ 1. Download and untar the source tarball
>
> 2. cd to xen-unstable (or whatever you sensibly rename it to).
>
> -On Linux:
> -
> -3. For the very first build, or if you want to destroy existing
> - .configs and build trees, perform the following steps:
> +3. For the very first build, or if you want to destroy build trees,
> + perform the following steps:
>
> # make world
> # make install
>
> This will create and install onto the local machine. It will build
> - the xen binary (xen.gz), and a linux kernel and modules that can be
> - used in both dom0 and an unprivileged guest kernel (vmlinuz-2.6.x-xen),
> - the tools and the documentation.
> + the xen binary (xen.gz), the tools and the documentation.
>
> You can override the destination for make install by setting DESTDIR
> to some value.
>
> - The make command line defaults to building the kernel vmlinuz-2.6.x-xen.
> - You can override this default by specifying KERNELS=kernelname. For
> - example, you can make two kernels - linux-2.6-xen0
> - and linux-2.6-xenU - which are smaller builds containing only selected
> - modules, intended primarily for developers that don't like to wait
> - for a full -xen kernel to build. The -xenU kernel is particularly small,
> - as it does not contain any physical device drivers, and hence is
> - only useful for guest domains.
> -
> - To make these two kernels, simply specify
> -
> - KERNELS="linux-2.6-xen0 linux-2.6-xenU"
> -
> - in the make command line.
> -
> 4. To rebuild an existing tree without modifying the config:
> # make dist
>
> - This will build and install xen, kernels, tools, and
> - docs into the local dist/ directory.
> + This will build and install xen, tools, and docs into the local dist/
> + directory.
>
> You can override the destination for make install by setting DISTDIR
> to some value.
> @@ -113,24 +100,7 @@ 4. To rebuild an existing tree without m
> version of hotplug or udev scripts, for example), but make dist
> includes all versions of those scripts, so that you can copy the dist
> directory to another machine and install from that distribution.
> -
> -5. To rebuild a kernel with a modified config:
> -
> - # make linux-2.6-xen-config CONFIGMODE=menuconfig (or xconfig)
> - # make linux-2.6-xen-build
> - # make linux-2.6-xen-install
> -
> - Depending on your config, you may need to use 'mkinitrd' to create
> - an initial ram disk, just like a native system e.g.
> - # depmod 2.6.18-xen
> - # mkinitrd -v -f --with=aacraid --with=sd_mod --with=scsi_mod
> initrd-2.6.18-xen.img 2.6.18-xen
> -
> - Other systems may requires the use of 'mkinitramfs' to create the
> - ram disk.
> - # depmod 2.6.18-xen
> - # mkinitramfs -o initrd-2.6.18-xen.img 2.6.18-xen
> -
> -
> +
> Python Runtime Libraries
> ========================
>
> diff -r ef7166e5640f -r 635270fe858b config/Linux.mk
> --- a/config/Linux.mk Fri Sep 10 09:55:19 2010 +0100
> +++ b/config/Linux.mk Fri Sep 10 11:09:10 2010 +0100
> @@ -1,11 +1,7 @@ include $(XEN_ROOT)/config/StdGNU.mk
> include $(XEN_ROOT)/config/StdGNU.mk
>
> # You may use wildcards, e.g. KERNELS=*2.6*
> -ifeq (ia64,$(XEN_TARGET_ARCH))
> -KERNELS ?= linux-2.6-xen
> -else
> -KERNELS ?= linux-2.6-pvops
> -endif
> +KERNELS ?=
>
> XKERNELS := $(foreach kernel, $(KERNELS), \
> $(patsubst buildconfigs/mk.%,%, \
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home