| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home