|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [RFC] bootloader improvements - pygrub-kernel-config
On Fri, Nov 10, 2006 at 08:14:28PM +0000, Daniel P. Berrange wrote:
> I'm not sure this is a good idea - its essentially completely inverting
> the current semantics for bootloader/kernel params in the config files.
> Currently a 'kernel' parameter will always override a 'bootloader' param,
> but with this change a 'bootloader' param will always override a 'kernel'
> param. I can see that both approaches have their merits, I don't think
> we can ever pick one prioritization rule which satisfies everyone here
> and thus for sake of compatability we should keep the current semantics
> for kernel/booloader prioritization in the configs.
Taken in concert with the other patch, the 'kernel' choice will always
be respected if it's set.
> > self.kernel = get_cfg("kernel")
> > + self.ramdisk = get_cfg("ramdisk", '')
> > + self.boot_kernel = get_cfg("boot_kernel")
> > + if not self.boot_kernel:
> > + self.boot_kernel = self.kernel
> > + self.boot_ramdisk = get_cfg("boot_ramdisk")
> > + if not self.boot_ramdisk:
> > + self.boot_ramdisk = self.ramdisk
> > +
>
> This is also changing the semantics of the SEXPR exposed by XenD - previously
> the ('vmlinux') and ('initrd') parameters would refer to the live kernel
> in the guest, but now you'd have to look at the boot_XXX variants instead.
>
> If we did want to change the prioritzation such that bootloader overrides
> any explicit kernel/initrd, then I think we should just have the values
> from bootloader directly overwrite the existing named SXPR fields rather
> than adding new boot_XX fields.
See the other patch. We could make it so kernel/initrd are always the
'live' ones, than we have cfg_kernel/cfg_initrd or something, but I
don't really see the advantage in that, and the disadvantage is
reasonably obvious: if I want to lookup to see "what kernel is this",
I'd have to check first cfg_kernel then kernel. With boot_*, I can
always look in 'kernel' and know that this is the one that the .py
config chose.
regards
john
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|