This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: Xen bootloader (was: Re: [Xen-devel] Xen Roadmap proposal)

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: Xen bootloader (was: Re: [Xen-devel] Xen Roadmap proposal)
From: Michael Loehr <MLOEHR@xxxxxxxxxx>
Date: Fri, 14 Jul 2006 15:26:10 +0200
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Anthony Liguori <aliguori@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, yhlu <yhlu.kernel@xxxxxxxxx>
Delivery-date: Fri, 14 Jul 2006 06:23:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200607141248.32241.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
So if I understand you right (i am not so firm in Xen terminology yet) you
currently have to load your guest kernel + ramdisk from a bootloader that
is running in the 'master' environment. This would mean you have to keep
kernel and ramdisk on a filesystem that is readable for the 'master'
environment. With a kexec based bootloader you would always load a
standardized kernel and ramdisk first. This mini-linux already runs in the
guest environment and acts as a boot loader. Because it is a complete linux
you can easily integrate support for all kinds of strange filesystems or
network protocols. Depending on a config file or controlled by user
interaction this boot loader linux will load the final guest system.

With our kboot_sl stuff we provide a prototype for such a type of boot
loader. Werner Almesberger did already something similar with his kboot
project which we used as our basis. To clarify the difference between these
two flavours of kexec based boot loaders a little bit:

- kboot is script based, designed to have a small footprint (uses uClibc,
busybox, dropbear) and it is expected that kernel and ramdisks are
customized for the target system.

- kboot_sl is built around a C program that interprets a configuration file
and can start various user interfaces. We decided to give up the size
restrictions, switched to glibc, integrated additional tools into the
ramdisk and will probably replace busybox and dropbear by the 'real thing'
sometime. We try to provide a more generic system loader ramdisk that can
be used without much customization to the target system.

So if you want to try the latter don't hesitate to ask me if anything is

best regards


Michael Loehr
Dept. A177, Bldg. 55131-12 / UG / 6C
Linux for zSeries Development
Hechtsheimer Str. 2
55131 Mainz, Germany
Phone +(49)-6131-84-3396, Fax -6592, Mobile +(49)-171-860-5354

Xen-devel mailing list