[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] bootloader improvements
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |