Re: [Xen-devel] [RFC] bootloader improvements

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Mon, Nov 13, 2006 at 10:09:01AM +0000, Tim Deegan wrote:

> > > I don't understand why this is needed.  Why not just not set a
> > > bootloader= option if you want the default?
> > 
> > I don't understand your point. The name and location of 'pygrub' should
> > be an internal detail unless somebody /wants/ to use a different
> > bootloader. It's a natural follow-on for the first patch.
> 
> Sorry, what I meant was, isn't not setting the bootloader option at all
> equivalent to setting it to "default"?  If you want to control whether
> the bootloader is called at all, there could be two config options, say,
> use_bootloader (default 0) and bootloader_path (default wherever pygrub is).

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.

> > > Hmmm.  I like the idea of splitting the bootloader's suggested
> > > kernel/etc from the config file's one, but I don't think the bootloader
> > > should be involved in that at all.  I'd rather have Xend be able to make
> > > a decision based on all the information from both sources.   This needs
> > > a bit more thought generally.
> > 
> > Could you expand a bit more on what you mean here?
> 
> I think that it would be better not to pass the config file options into
> pygrub and back out again: pygrub presumably has no business changing
> those fields anyway.  In future, if pygrub supplies more configuration
> options, will we have to add a command-line option for each one so it
> can pass the config file versions through?  It just seems a bit messy.

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". Equally I'd like to split the code up a bit further into
"load this file" code and "run interactive pygrub" code.

> Could Xend not just run the bootloader and then, say, fall back to the
> values it got from the config file if it doesn't get anything from the 
> bootloader?

That would enforce interactive usage.

> > Why? I don't understand why replacing a hands-off method with a load of
> > interactive gook is a step forward.
> 
> It would let you dual-boot a linux/Solaris guest. :)  It would mean that
> if you untarred a Solaris kernel in your linux guest your Grub menu
> woudn't just go away forever.

hmm :)

> It would let you choose a "backup" Solaris kernel if your main one got
> toasted.   All the usual things a boot menu is useful for. 

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.

regards,
john

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel