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 - pygrub-kernel-config

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] bootloader improvements - pygrub-kernel-config
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Fri, 10 Nov 2006 21:10:43 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 10 Nov 2006 13:11:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061110201428.GH19736@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20061109192017.GA16487@xxxxxxxxxxxxxxxxxxxx> <20061109192240.GC16717@xxxxxxxxxxxxxxxxxxxx> <20061110201428.GH19736@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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