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

[Jeremy Katz <katzj@xxxxxxxxxx>]

On Thu, 2006-03-02 at 12:36 +0000, John Levon wrote:
> On Wed, Mar 01, 2006 at 11:53:08PM -0500, Jeremy Katz wrote:
> > > 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.
> 
> Yes. However, it is not right to *demand* that the bootloader provide
> all of these. This is the case with the current interface:

What's the use case for _not_ having them set by the boot loader?

> > > 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
> 
> Simplicity is not the issue, stability is. This sounds like you want to
> change it already.

Adding entry points can be done without breaking existing code if future
filesystems need support for more things.  I think you're reading a lot
more into that statement than was intended

> > 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.
> 
> Until such a time that grub is ported to Xen and all domU's are updated,
> it does not make sense to use a config file of an unrelated program to
> hold this data. And when that does happen, pygrub can be deleted as
> well.

Why not?  For a concrete example -- we have a set of utilities that are
used for updating the grub.conf when you install a new kernel.  If you
install a new kernel inside a guest, you want the same basic idea to
occur -- you want the config file that says what kernel to boot to be
updated with information on the new kernel.  Going with a different
format means that tools need significant overhauling to work in a
paravirtualized guest instead of just working.  There are *huge*
benefits here.

> > > 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. 
> 
> Except that pygrub isn't assumed which both requires the pygrub-specific
> "bootentry" and 

Nothing in Xen right now "assumes" pygrub.  All of the code generically
calls just an executable and expects to read an sxp back on a pipe.
This was done explicitly as there were a few people that wanted to be
able to experiment with other boot loaders.  I half-expected to see
someone do a LILO clone :)

You don't want to use stdout as if you use stdout, your boot loader now
has no way to actually let the user make any changes.  As I said, the
bootentry stuff was added at the request of someone on the list.  

> ignores kernel/ramdisk choices.

Ignores it how?

> > > 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?  
> 
> For grub method, the boot entry, and later, the kernel if wanted. For
> root method, kernel/ramdisk path. For XXX bootloader, some
> method-specific parameters. 

The entire goal of the boot loader code is to move determination of what
to boot _out_ of dom0 and into domU, so passing the kernel and ramdisk
seems somewhat counter to that goal.  I really have a hard time seeing
parameters which would be specific to kernel or ramdisk -- an easy way
to pass args to the boot loader binary doesn't seem unreasonable[1] and
far less overhead to accomplish. 

Jeremy

[1] although it probably works if you just do bootloader="/usr/bin/foo
myargs" now


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