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] [PATCH] Don't attach needless options when launch pygrub

On Wed, 2010-07-14 at 10:36 +0100, Yu Zhiguo wrote:
> Ian Campbell wrote:
> > 
> > As far as I can see the --kernel and --ramdisk options end up in the
> > incfg map which only used in a handful of places, most of which just
> > extract incfg["args"]. The only places which do not do this are the
> > calls to sniff_solaris and sniff_netware both of which appear to make
> > use of incfg["kernel"] (but not incfg["ramdisk"]).
> > 
> > So it looks like specifying the kernel option in addition to bootloader
> > is infact useful if you are booting a Solaris or Netware domU but is
> > harmless/ignored otherwise. I think we need to continue to support this
> 
>  It seems that incfg will be returned directly if DomU is not Solaris,
> 
> def sniff_solaris(fs, cfg):
>     if not fs.file_exists("/platform/i86xpv/kernel/unix"):
>         return cfg
> 
> 
>     chosencfg = sniff_solaris(fs, incfg)
> 
>  So, incfg change to chosencfg and then will be used.

Oh yes, this stuff seems needlessly complex, or at least prone to
misreading, by me at least ;-)

You are right that chosencfg will be updated by sniff_solaris to be the
same as incfg if Solaris is not present (similarly for netware). 
Eventually we do "fs.open_file(chosencfg["kernel"]).read()" i.e. the
specified kernel from incfg will be read from the guest filesystem, as I
first expected.

All this is long standing behaviour, remind me why do you want to change
it?
[...]
>  What about copy the specified 'kernel' from DomU to a temp file.
> If there are 'bootloader' but no 'kernel', pygrub will copy and create temp 
> file.
> We can do the same things.

I think this is the current behaviour.

Ian.



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