[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] disable kernel build in Xen build system


  • To: Ian Campbell <ian.campbell@xxxxxxxxxx>, Pasi Kärkkäinen <pasik@xxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Fri, 10 Sep 2010 12:04:00 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 10 Sep 2010 04:06:41 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=D1lhr+0dYeh80j8AkI9GYGF/RjEkWKx19X+7Xxt6Cxjs4Jc9fCW2NXFsy4UbSzXAo6 AH6TuYhFvQV+iSS+Z8vTZiThmiTJg/hLk7u1SLxHbh4Lcq8t/3nKCyQ/B98+I33rTbVN sfWPewsK2n2k1e5yOD8hx3hq/DqjD+YFsW2lc=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.