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