Xen project Mailing List

[Xen-changelog] [xen-unstable] Disable kernel build in Xen build system.

From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>

Date: Wed, 15 Sep 2010 07:40:31 -0700

Delivery-date: Wed, 15 Sep 2010 07:46:00 -0700

List-id: BK change log <xen-changelog.lists.xensource.com>

# HG changeset patch # User Keir Fraser <keir.fraser@xxxxxxxxxx> # Date 1284395479 -3600 # Node ID f61504f8d6e51499b554dc06b672dc2d9786f88c # Parent 35318cc05a50528d8e15585c23cf4578c31702c3 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> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> --- README | 58 +++++++++++++------------------------------------------- config/Linux.mk | 6 ----- 2 files changed, 15 insertions(+), 49 deletions(-) diff -r 35318cc05a50 -r f61504f8d6e5 README --- a/README Mon Sep 13 17:29:53 2010 +0100 +++ b/README Mon Sep 13 17:31:19 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 35318cc05a50 -r f61504f8d6e5 config/Linux.mk --- a/config/Linux.mk Mon Sep 13 17:29:53 2010 +0100 +++ b/config/Linux.mk Mon Sep 13 17:31:19 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-changelog mailing list Xen-changelog@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-changelog

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.