From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YnTVo-0005GI-Es for mharc-grub-devel@gnu.org; Wed, 29 Apr 2015 11:02:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnTVl-0005G0-IB for grub-devel@gnu.org; Wed, 29 Apr 2015 11:02:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnTVk-0005Ie-8b for grub-devel@gnu.org; Wed, 29 Apr 2015 11:02:53 -0400 Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:38020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnTVk-0005Ia-1u for grub-devel@gnu.org; Wed, 29 Apr 2015 11:02:52 -0400 Received: by wiun10 with SMTP id n10so69319690wiu.1 for ; Wed, 29 Apr 2015 08:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=UgvhHdDugwoIVGQp25Fd/cg+SveTpUorJpkcv1YZW1Y=; b=gPkY2p4TfVvH/YGBtOTLm3iHyFewvshLKm3ZpMs0zJ9Aihg5G0zvhRJxsN2gFHTG65 wbqx9n/bHlMFCYi0HTFx3i0V+ULbIIPMA5lOh07ALu17sR6CHsgDhYpEsVBu/55LL2yn wzq94X4684GeDZTlS/Yw7W6bejrjh2kfdqTc52WdcLo27ny9v7tnvtPF3ZiDAFYxqwTS 9ih1g4ntXz8DmJj1Pg0tIUDfWHF7xiNeFZtsa3RkW0pMXg8ROtdJFaoe2soY+SFdWbYq CzNMWYWk78a7GH5ovqo7MdQMvJtZGiofP+GBq36fBREkRaML8490kdUJhWQm1NOJ/QSk A0Nw== X-Received: by 10.180.100.101 with SMTP id ex5mr6791867wib.13.1430319771385; Wed, 29 Apr 2015 08:02:51 -0700 (PDT) Received: from ?IPv6:2620:0:105f:fd00:863a:4bff:fe50:abc4? ([2620:0:105f:fd00:863a:4bff:fe50:abc4]) by mx.google.com with ESMTPSA id em18sm15686122wjd.19.2015.04.29.08.02.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 08:02:50 -0700 (PDT) Message-ID: <5540F299.4020304@gmail.com> Date: Wed, 29 Apr 2015 17:02:49 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: passing options to grub in xen,openfirmware and efi References: <20150423080306.GA15265@aepfle.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G5bKahvDGkeEqoeOEAHrK95LlEnX3XKje" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::229 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 15:02:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G5bKahvDGkeEqoeOEAHrK95LlEnX3XKje Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23.04.2015 11:35, Andrei Borzenkov wrote: > On Thu, Apr 23, 2015 at 11:03 AM, Olaf Hering wrote: >> >> Is there a way to pass options to grub in a Xen PV domU, in openfirmwa= re >> and in EFI environment? >> >> In a PV domU arguments can be passed to the specified >> kernel=3D"/path/file" with the extra=3D"what ever" option. >> In openfirmware the arguments may come from the /boot/chosen node. >> In EFI it may be possible as well, not my area of expertise. >> In the wellknown dumb i386 BIOS no such way exist. >> >> In case grub has code to evalute these things, how can such arguements= >> be used within grub.cfg? Where is that documented? >> >=20 > I believe the question briefly came up already but without any > followup. IIRC it was in relation to how to pass real kernel name to > grub in Xen. >=20 > For OFW grub will parse bootargs property, interpret it as series of > variable assignments separated by ";" and set these variables. There > is nothing similar for Xen or EFI cases currently. For EFI we could > fetch arguments using Loaded Image Protocol (LoadOptions). Another > option (in addition, not either/or) is to define GUID for grub and set > them in NVRAM. >=20 > What I do not like is the possibility to blindly set any internal > variable (consider overriding of $prefix). I'd prefer to set variables > in separate namespace, like grub.arg.XXX=3DYYY for XXX=3DYYY argument a= nd > let user figure out what to do with them. I'm aware of the problem and I fully agree with you. Automatic install doesn't use those and I think the reason for it was to specify root in early days of porting. I don't think it's used for anything nowadays. Also unless there is a good usecase for having command line parsing, I'm all for killing existing ieee1275 parsing altogether and not introducing any parsing in the future. >=20 > As long as variables are defined you of course can do whatever you > like with them, including referencing them in grub.cfg. How you can > use them in grub.cfg is limited only by your imagination then :) >=20 > I do not think it is documented anywhere mostly because feature does > not really exist; I suppose OFW was added mostly as prerequisite for > something else. git blame may answer it. >=20 > And of course patches are welcome :) >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --G5bKahvDGkeEqoeOEAHrK95LlEnX3XKje Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREKAAYFAlVA8poACgkQmBXlbbo5nOtgnQD/fwdQzaG7gk2DTTBMbO+147AK 3gpCHDCLSieOQcBHQucA/3FYacV61cL9D58ZWIiKKBnn+fTIfTfz4Q+5SHHV3Rqi =91X5 -----END PGP SIGNATURE----- --G5bKahvDGkeEqoeOEAHrK95LlEnX3XKje--