14 messages in com.xensource.lists.xen-develRe: [Xen-devel] [RFC] Bootloader conf...| From | Sent On | Attachments |
|---|---|---|
| John Levon | 27 Feb 2006 08:46 | |
| Ian Pratt | 27 Feb 2006 14:13 | |
| Tim Deegan | 28 Feb 2006 01:44 | |
| John Levon | 28 Feb 2006 07:14 | |
| Tim Deegan | 28 Feb 2006 12:31 | |
| John Levon | 28 Feb 2006 12:39 | |
| Tim Deegan | 01 Mar 2006 08:52 | |
| Hollis Blanchard | 01 Mar 2006 15:10 | |
| Jeremy Katz | 01 Mar 2006 20:52 | |
| Jeremy Katz | 01 Mar 2006 20:52 | |
| John Levon | 02 Mar 2006 04:36 | |
| John Levon | 02 Mar 2006 04:45 | |
| Jeremy Katz | 02 Mar 2006 15:34 | |
| John Levon | 02 Mar 2006 16:04 |
| Subject: | Re: [Xen-devel] [RFC] Bootloader configuration |
|---|---|
| From: | Jeremy Katz (kat...@redhat.com) |
| Date: | 03/02/2006 03:34:35 PM |
| List: | com.xensource.lists.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-...@lists.xensource.com http://lists.xensource.com/xen-devel