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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Don't attach needless options when launch pygrub
From: Yu Zhiguo <yuzg@xxxxxxxxxxxxxx>
Date: Wed, 14 Jul 2010 17:36:20 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 14 Jul 2010 02:37:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1279095028.24714.186.camel@xxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C3D55F8.9010303@xxxxxxxxxxxxxx> <1279090052.13417.16.camel@xxxxxxxxxxxxxxxxxxxxx> <4C3D6755.3020400@xxxxxxxxxxxxxx> <1279095028.24714.186.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 3.0a1 (Windows/2008050715)
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.

 Should we fix sniff_solaris let it don't modify chosencfg if DomU
is not Solaris at least?


> use case and I don't see any particular reason to force those users to
> change their configuration file syntax for this issue (if it's even an
> issue, I still don't really see the problem).
> 
> Perhaps it would be better to update pygrub so that --kernel actually
> does something consistent in the non-{Solaris,Netware} case, such as
> perhaps selecting the configuration entry with the match kernel path
> instead of defaulting to entry 0? (e.g. make "-q --kernel=/boot/FOO"
> select the entry with kernel /boot/FOO)
> 

 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.

Yu

> It looks like --ramdisk (and the associated plumbing through xend) may
> in fact be useless at this time. I'd say it is harmless to plumb it
> through for consistency though -- perhaps in the future pygrub (or
> another bootloader) might want to use it.
> 
> Ian.
> 
> 
> 
> 


-- 
Regards
Yu Zhiguo
--------------------------------------------------
Yu Zhiguo
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630566-853
COINS: 79955-853
FAX: +86+25-83317685
MAIL: yuzg@xxxxxxxxxxxxxx
--------------------------------------------------
This communication is for use by the intended recipient(s) only and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you are not an intended recipient of this communication, you 
are hereby notified that any dissemination, distribution or copying hereof is 
strictly prohibited.  If you have received this communication in error, please 
notify me by reply e-mail, permanently delete this communication from your 
system, and destroy any hard copies you may have printed.


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