Xen devel - Feb 2006 - [RFC] Bootloader configuration

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
2) ''bootentry'' is highly pygrub-specific. There is no easy
facility to specify
   any options for custom bootloaders
3) bootloaders are forced to return configuration params like
''args'', since
   the code assumes it knows all with regards to image.py
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

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
2) Filesystem support needs to be delivered into the correct python
   directory, and carefully match the exact internal API used by pygrub
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.
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.

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:

kernel = "method:method-params"
ramdisk = "method:method-params"

If no method is specified, it defaults to ''path''. The path
method is a null
bootloader that just sets the output parameters to the file specified, i.e.
these are equivalent:

kernel = "/path/to/vmlinuz"
kernel = "path:/path/to/vmlinuz"

IOW, "path" means a file is on the dom0 fs tree.

The options ''bootloader'' and ''bootentry'' are
removed: the method specification
replaces ''bootloader'', and (for the ''grub''
method) the method-params replaces
''bootentry''.

In addition, a new option ''bootdisk'' is added. This is a
method-specific value
that''s interpreted as desired by the bootloader method. This is
required if not
using the ''path'' bootloader.

The ramdisk method, if ''ramdisk'' is present, must equal the
''kernel'' method.

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>

When found, the bootloader is invoked as follows:

     -b <bootdisk> -k <kernel''s method-param> [-r
<ramdisk''s method-param>] \
        -d <disk1> [ -d <disk2> ... ]

and is expected to return, on stdout, any of these lines:

     kernel=/path/to/kernel/file
     ramdisk=/path/to/ramdisk/file
     extra=...
     root=...
     cmdline_ip=...

If some of these are omitted, the config file''s version is used.

This hopefully is generic enough to deal with, for example, Kurt''s
mount -o
loop approach, by defining a /usr/lib/xen/boot/bootload-loop script, as well as
a ''grub'' method which will be a modified pygrub.

To deal with the most common case, I''d also like to propose a standard
''root''
bootloader:

''root'' bootload method
----------------------

A bootloader ''root'' should be delivered as
/usr/lib/xen/boot/bootload-root. It
will match up a bootdisk entry such as ''sda3'' against the disk
specifications
passed in and construct a path to the fs image residing on a file or device
node. Once the FS image is located, it will call out to a generic OS-provided
helper called ''readfs'' as follows:

        readfs -n -i <image> -o /var/cache/xen/boot/<file>
<file>

This binary will identify the filesystem and read the file given off it,
storing it in the output cache file specified if it has changed since last
invocation.

After doing this for the kernel and possibly ramdisk, bootload-root will print
the locations of the cached files back to the bootloader handler and quit.

The intention for readfs is to provide a generic utility for grabbing files
from an image without having to loopback mount the filesystem. I want to make
this call out to fs-specific helpers so it''s possible to boot
domU''s of
"foreign" operating systems on foreign file systems. In particular
I''m very
interested in getting a readfs package integrated into the big free
OS''s that
are/will be domain 0 (Solaris, Linux, and the BSDs) with a number of backends
for different filesystems.

I already have a rough prototype of this setup for root/grub bootloaders that
seems to work reasonably.

All comments welcomed,
john

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

> 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>
> 
> When found, the bootloader is invoked as follows:
> 
>      -b <bootdisk> -k <kernel''s method-param> [-r
<ramdisk''s
> method-param>] \
>         -d <disk1> [ -d <disk2> ... ]
In principle, I think invoking a binary to run the boot loader is
probably a good thing. It''s quite possible we''ll want to drop
in new
guest-specific boot loader binaries. 

Ian

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

On Mon, Feb 27, 2006 at 04:47:03PM +0000, John Levon
wrote:
> 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.
Surely this is somewhere that Python can be very useful!  Support for
filesystem reading is available in C libraries, and munging a lot of C
interfaces together into a command-line tool is one of the things Python
does best.

In general I agree with your ideas; my own patches to XM and pygrub for
this were going along these lines, if not quite general enough.  In the
long term though, in-domU support is going to be the best way of doing
this, specially for virtual hosting and "packaged" VM images.

Tim.

-- 
Tim Deegan                           (My opinions, not the
University''s)
Systems Research Group
University of Cambridge Computer Laboratory

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

On Tue, Feb 28, 2006 at 09:45:06AM +0000, Tim Deegan wrote:
> > 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.
> 
> Surely this is somewhere that Python can be very useful!  Support for
> filesystem reading is available in C libraries, and munging a lot of C
> interfaces together into a command-line tool is one of the things Python
> does best.
I''m not against "readfs" being written in Python as such,
just only a
Python API being presented. That is, I think the most useful interface
form is that of a command-line utility.

As it happens, my current prototype is written in C (ext2, and UFS) as
it''s very little code with a shell script frontend calling into the
backends.
> In general I agree with your ideas; my own patches to XM and pygrub for
> this were going along these lines, if not quite general enough.  In the
> long term though, in-domU support is going to be the best way of doing
> this, specially for virtual hosting and "packaged" VM images.
Are you referring to a grub Xen port, or the "boot something once to get
images" thing that''s been discussed, or something else?

cheers,
john

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

On Tue, Feb 28, 2006 at 03:15:07PM +0000, John Levon
wrote:
> Are you referring to a grub Xen port, or the "boot something once to
get
> images" thing that''s been discussed, or something else?
A grub port (or similar) seems like the most useful thing.  The less
dom0 has to understand about domU''s kernel/fs peculiarities, and the
less fs, config and loader code that needs to be rewritten just for Xen,
the better.

I think the xm config runes defining a domain should only need to be
changed for something that would be a hardware upgrade in non-virtual
hosting.  Any purely software changes within the domain (including
change of os/fs) shouldn''t require intervention by a dom0
administrator.

Tim.

-- 
Tim Deegan                           (My opinions, not the
University''s)
Systems Research Group
University of Cambridge Computer Laboratory

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

On Tue, Feb 28, 2006 at 08:31:55PM +0000, Tim Deegan wrote:
> A grub port (or similar) seems like the most useful thing.
Right. AFAIK nobody is working on this right now.
>  The less dom0 has to understand about domU''s kernel/fs
peculiarities,
>  and the less fs, config and loader code that needs to be rewritten
>  just for Xen, the better.

Agreed. (As I noted, one of the reasons I wanted ''readfs'' was
so that
all code was part of the provided OS facilities on dom0, not part of the
Xen project as such.)

regards
john

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

On Tue, Feb 28, 2006 at 08:40:16PM +0000, John Levon
wrote:
> On Tue, Feb 28, 2006 at 08:31:55PM +0000, Tim Deegan wrote:
> > A grub port (or similar) seems like the most useful thing.
> 
> Right. AFAIK nobody is working on this right now.
I hope to have some time to work on it soon.

Tim.

-- 
Tim Deegan                           (My opinions, not the
University''s)
Systems Research Group
University of Cambridge Computer Laboratory

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

On Tuesday 28 February 2006 14:40, John Levon wrote:
> On Tue, Feb 28, 2006 at 08:31:55PM +0000, Tim Deegan wrote:
> 
> > A grub port (or similar) seems like the most useful thing.
> 
> Right. AFAIK nobody is working on this right now.
GRUB already implements its own read-only filesystem drivers for a variety of 
filesystems. It sounds like your "readfs" would be duplicating this
work.
> >  The less dom0 has to understand about domU''s kernel/fs
peculiarities,
> >  and the less fs, config and loader code that needs to be rewritten
> >  just for Xen, the better.
I suppose it would also be nice not to need dom0 access to modify a
domU''s
kernel.

GRUB2 is conveniently very modular. You implement a block driver (Open 
Firmware and BIOS drivers are already implemented), and then the filesystem 
drivers "just work." You would want to write a small
"blkfront" driver and
see exactly how little code you can get away with.

I am a GRUB2 developer and would be happy to help if you have questions.

-- 
Hollis Blanchard
IBM Linux Technology Center

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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2006-03-01 at 17:10 -0600, Hollis Blanchard
wrote:
> On Tuesday 28 February 2006 14:40, John Levon wrote:
> > On Tue, Feb 28, 2006 at 08:31:55PM +0000, Tim Deegan wrote:
> > > A grub port (or similar) seems like the most useful thing.
> > 
> > Right. AFAIK nobody is working on this right now.
> 
> GRUB already implements its own read-only filesystem drivers for a variety
of
> filesystems. It sounds like your "readfs" would be duplicating
this work.
Well, GRUB is also duplicating plenty of work.  Filesystem code is fun!
Well, or not ;-)
> > >  The less dom0 has to understand about domU''s kernel/fs
peculiarities,
> > >  and the less fs, config and loader code that needs to be
rewritten
> > >  just for Xen, the better.
> 
> I suppose it would also be nice not to need dom0 access to modify a
domU''s
> kernel.
That''s the whole point behind the boot loader interface and pygrub as
it
currently exists.
> GRUB2 is conveniently very modular. You implement a block driver (Open 
> Firmware and BIOS drivers are already implemented), and then the filesystem
> drivers "just work." You would want to write a small
"blkfront" driver and
> see exactly how little code you can get away with.
Yeah, I had started to look at using the filesystem drivers for use in
pygrub -- there''s a lot of grub2 which is less applicable for
bootstrapping a domU, but re-inventing the wheel of filesystem reading
code is overkill.

Jeremy


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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Mar 01, 2006 at 11:53:09PM -0500, Jeremy Katz wrote:
> On Wed, 2006-03-01 at 17:10 -0600, Hollis Blanchard wrote:
> > On Tuesday 28 February 2006 14:40, John Levon wrote:
> > > On Tue, Feb 28, 2006 at 08:31:55PM +0000, Tim Deegan wrote:
> > > > A grub port (or similar) seems like the most useful thing.
> > > 
> > > Right. AFAIK nobody is working on this right now.
> > 
> > GRUB already implements its own read-only filesystem drivers for a
variety of
> > filesystems. It sounds like your "readfs" would be
duplicating this work.
> 
> Well, GRUB is also duplicating plenty of work.  Filesystem code is fun!
> Well, or not ;-)
For some reason I didn''t get Hollis''s original post. Anyway,
he''s right
that there''s a certain amount of code duplication, but certainly very
little for filesystems that provide a userspace library. I cannot think
of a sane way to share this code (just like the grub authors could not
share the kernel''s version).

I do believe that readfs is generally useful.

regards,
john

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

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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Mar 02, 2006 at 06:34:58PM -0500, Jeremy Katz wrote:
> > 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?
Something that just needs to grab the kernel and ramdisk file, and leave
the settings to the config file. Like readfs or Kurt Garloff''s mount -o
loop bootloader. IIRC you already have some weird logic where you pass
in the vcpus spec and then pass it back out.
> > 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.
This will certainly be the case for your particular setup in Fedora.
This is one of the reasons I''m *not* proposing removing pygrub! This is
all about making bootloading more flexible for setups other than Fedora
on Fedora.

I have no intention of breaking any plans you have with regards to
pygrub.
> > 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 :)
Then I''m not sure why you''re so against generalising the
bootloader
facilities?
> 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.
I''ve already recoded pygrub to open itself on /dev/tty. I do not expect
the majority of bootloaders to be interactive, and I wanted to keep the
interface simple, especially as the code at the time was rather broken
wrt the fifo. (Anyway, this is very much an implementation detail, I''m
more concerned with the issues you have regarding the design).
> 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.
It''s certainly counter to your goals for your particular setup. There
are other ways to approach this, though.
> 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. 
> 
> [1] although it probably works if you just do bootloader="/usr/bin/foo
> myargs" now
My memory might be faulty, but I think this didn''t work. I''m
not averse
to some modification of the syntax here. As an alternative:

1) dump bootentry

2) keep bootloader, where:

	bootloader="<name> <args>"

For the name we keep the default search-path I previously described so
users can do:

	bootloader="root"

Or use a fully-specified path. Would this be more reasonable to you?
It''s a little more verbose but I wouldn''t object.

regards,
john

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