WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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