At 13:42 +0000 on 13 Nov (1163425323), John Levon wrote:
> No, if you specify kernel then it's picked up from the dom0 filesystem.
> And I want to avoid having to insist on the bootloader_path at all: the
> common case (using pygrub) should just work.
If we have a use-a-bootloader flag, which defaults to off if a kernel is
specified, and a which-bootloader-should-i-use path, which defaults to
wherever pygrub lives on this system, does that covers all the angles?
I find both the idea of having a "default" keyword at all and the idea
that explicitly requesting the default (!) has side-effects to be
unintuitive.
> I agree it's messy. In fact I'd rather like to rework the interface to
> read the config from an fd and write it back to another. It's a
> requirement to pass the details in, otherwise we cannot say "load me
> /this/ kernel".
Yes, I see. So now I like the pygrub-nogrub patch more. :)
As it stands, passing a kernel= option causes pygrub not to bother
looking for menu options, yes?
> Equally I'd like to split the code up a bit further into
> "load this file" code and "run interactive pygrub" code.
Hmmm. Let me try and untangle what we require now...
1) Receive kernel, args and initrd choices from xm config.
2) Find and parse a GRUB menu.lst in a filesystem image.
3) Automatically detect a Solaris installation in a filesystem image.
4) Let the user choose and modify their boot options.
5) Extract a particular file from a filesystem image for booting.
We should always do all three of 1, 2 and 3: no such thing as too many
options. I would like to see stage 4 available regardless of which of
stages 1, 2 and 3 provide boot options (including none). Letting the
user choose seems like it should always be the right idea.
There's also a question of weighting: if we run non-interactively (or
time out in interactive mode) what should we do by default? My
inclination is to listen to menu.lst first, then autodetected kernels,
and then the config-file-provided kernel.
> Plus all the problems. It's trading the 99.9% case on Solaris ("boot the
> kernel you always boot") for the rare exception ("I totally screwed up
> my machine", "I'm a Solaris kernel developer running a different
> kernel") which can be handled much better via the .py config file.
I have a particular dislike of having to make changes to the xm config
file; as far as I'm concerned, a major goal of having all this
bootloader code is that eventually only "hardware" changes will need to
be made in dom0 and *all* software configuration will be inside the
guest filesystem.
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home