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

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

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:

    if vals.bootloader:
        config.append(['bootloader', vals.bootloader])
        config_image = run_bootloader(vals)

> > 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.

Well, that would certainly be good. But see my comments regarding the
general utility of readfs.

> > 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.

> > 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.

I'm not even necessarily talking about closed source, and I do not want
to get into a fruitless "discussion" about licensing to be honest. The
Xen sources have gone to a significant amount of effort to allow non-GPL
compatible guests already. I do not accept that it is the intent of the
Xen project to require all platform-provided guest domain code to be
GPLed.

> 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.

> > 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 :)

That indeed may be your opinion, but I am not seeing a universal use of
pygrub. But that isn't even the issue here: this general scheme allows
anything to be passed to a custom bootloader, not necessarily specify
paths to the kernel/ramdisk.

> > 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 ignores kernel/ramdisk choices.

> > 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. That's the point, it doesn't tie all domU's
into some Fedora-specific approach.

regards,
john

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