Re: [Xen-devel] [RFC] Bootloader configuration

[Jeremy Katz <katzj@xxxxxxxxxx>]

On Mon, 2006-02-27 at 16:47 +0000, John Levon wrote:
> This is a proposal for modifying the interface for domU bootloaders (i.e.
> something that provides us with a kernel and ramdisk file with which the 
> domain
> can be booted). The current interface, as is, has a number of problems,
> including:
> 
> 1) the first disk specified is assumed to be the disk containing the files

Well, this isn't that different than a BIOS :-)  

> 2) 'bootentry' is highly pygrub-specific. There is no easy facility to specify
>    any options for custom bootloaders

This was largely added at the request of someone to be able to change...
I think that having it at all makes little sense, realistically

> 3) bootloaders are forced to return configuration params like 'args', since
>    the code assumes it knows all with regards to image.py

A boot loader _does_ need to pass back everything regarding an image,
though.  All of kernel, initrd and arguments can and should be
accessible/modifiable by the boot loader.

> 4) users need to configure 'bootloader' by hand. There's little facility for
>    standard Xen-shipped bootloaders that can be easily chosen in the config
>    file

With the stuff that we're shipping in Fedora Core 5, we're setting up
guest domains to use pygrub by default.  I don't see this as being
different than "there's little facility for standard Xen-shipped kernels
to be easily chosen"

> In addition, the common case of "just get these files off the filesystem at
> this device" is not, IMO, well-covered by pygrub, the only bootloader shipped
> so far:
> 
> 1) Filesystem support requires a C/Python interface which contains a lot of
>    glue code, typically interfacing a C library to pygrub's internal API

Based on a couple of discussions I had in Austin, I think the right
thing to do here is probably to get to where we can use the grub2
filesystem modules.  It shouldn't be that bad to do, I've just been
caught up with some more mundane things instead of having time to get
around to it yet.

> 2) Filesystem support needs to be delivered into the correct python
>    directory, and carefully match the exact internal API used by pygrub

It's hardly that complicated of an API.  Actually, it's probably too
simple more than anything

> 3) There are possibly licensing inflexibilities with the fs-specific python
>    modules. Not really a big problem with the standard open OS's filesystems,
>    but I can easily imagine this being a problem with vendor filesystems, or
>    other operating systems.

I think that encouraging closed source implementations here is a bad
idea for allowing interoperability between guests.

> 4) The concept of "retrieve a file from this fs image" seems to be generically
>    useful outside of the Xen project context; forcing a Python API for this
>    functionality seems a lot less general than it should be.

> 5) IMO, it doesn't make sense to be using grub config files anyway. grub can't
>    boot domU's natively (typically), and pygrub obviously can't do vice versa.
>    The config syntax has a lot of things that aren't relevant to the domU 
> case.
>    At least, the pygrub approach needs to be optional rather than the primary
>    bootloading method.

Why invent yet another config file format that everything that anyone
would want to use within a guest has to be able to parse instead?  Sure,
the grub syntax has its warts, but it works well enough.  And creating
something else involves a completely separate knowledge set for users
inside of a guest vs on physical machines.

> This proposal covers three parts: the configuration file changes, the
> bootloader interface, and the new 'root' bootloader.
> 
> Config file
> -----------
> 
> Taking a lead from the disk configuration, the 'kernel' and 'ramdisk' options
> are extended to the format:

*shrug*  I continue to think that specifying kernel and ramdisk from
dom0 is non-interesting :)

> Bootloader interface
> --------------------
> 
> The Xen python code parses the 'kernel' value into 'method' and 'params', then
> searches for a bootloader handler matching 'method' as follows:
> 
>      /usr/lib/xen/boot/bootload-<method>
>      <auxbinpath>/bootload-<method>
>      /etc/xen/scripts/bootload-<method>

Since you have to specify the same method for kernel and ramdisk, this
is pretty much the same as the current bootloader config option. 

> When found, the bootloader is invoked as follows:
> 
>      -b <bootdisk> -k <kernel's method-param> [-r <ramdisk's method-param>] \
>         -d <disk1> [ -d <disk2> ... ]

What params do you see making sense here?  

Jeremy


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel