| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC] Bootloader configuration
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home