From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZwpLn-0003Km-Rk for mharc-grub-devel@gnu.org; Thu, 12 Nov 2015 05:43:31 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwpLl-0003JG-OT for grub-devel@gnu.org; Thu, 12 Nov 2015 05:43:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwpLk-0001Nb-P3 for grub-devel@gnu.org; Thu, 12 Nov 2015 05:43:29 -0500 Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:33489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwpLk-0001NX-JE for grub-devel@gnu.org; Thu, 12 Nov 2015 05:43:28 -0500 Received: by wmec201 with SMTP id c201so26166563wme.0 for ; Thu, 12 Nov 2015 02:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=R1fylpNKR84q6uqqQ3dIAYDDl3UlxHWfvaCTWjTmly4=; b=CHoeH5iIax/3SZxmXz+RLdP8GFeDUFQHNiOYjq1vjTjNIgrw0eowe6Flu/mUAAY/3N 4+uxTqw70eExu3DFii5t5iylJOBpP8dsDDtV1yS3+F2/tUNArXPNP4NNdcHLPOnyCRGy XbYFwzdcRhhh/H64XQqPkrKKt8p/0qNyd3pF2M4jRTAkEoAoVcJyzuGZtLT4aSMH+v0B tSqof9qdh6HrnUnkiOw7E3+A9IUhtqtaq7uLug8NRnITsUhPKInVqhC1gFWpVI21QYHp j2MALZklG935UEFMeqRjijFX3+JsFPmBZmo7nFOYjUTDH0yyrSFJzqHEtzI7LqwqVAzR FFsA== X-Received: by 10.28.125.201 with SMTP id y192mr9741178wmc.23.1447325008009; Thu, 12 Nov 2015 02:43:28 -0800 (PST) Received: from ?IPv6:2620:0:105f:fd00:863a:4bff:fe50:abc4? ([2620:0:105f:fd00:863a:4bff:fe50:abc4]) by smtp.gmail.com with ESMTPSA id 77sm14319159wml.20.2015.11.12.02.43.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 02:43:26 -0800 (PST) Subject: Re: [PATCH v3 3/4] * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 To: Andrei Borzenkov , The development of GRUB 2 References: <=fu.wei@linaro.org> <1437628583-23667-1-git-send-email-fu.wei@linaro.org> <1437628583-23667-4-git-send-email-fu.wei@linaro.org> <56323A72.3000905@gmail.com> <56333D6A.2080506@gmail.com> From: =?UTF-8?Q?Vladimir_'=cf=86-coder/phcoder'_Serbinenko?= X-Enigmail-Draft-Status: N1110 Message-ID: <56446D47.60400@gmail.com> Date: Thu, 12 Nov 2015 11:43:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oFuEMO4LamknvE7h4k007GUg2kn23jLLD" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::231 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: Thu, 12 Nov 2015 10:43:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oFuEMO4LamknvE7h4k007GUg2kn23jLLD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10.11.2015 08:01, Andrei Borzenkov wrote: > Not really, although this is a good observation. Actually I think that > xen_initrd should indeed have behavior 1, because what it does is > provide initrd image to Linux kernel, and - although not often used - > initrd image may be constructed by concatenation. >=20 > But what I meant - initially it was intended to have xen_module with > some options. As soon as we add option parsing we must have defined > way to differentiate between opption for xen_module itself and option > for module loaded by xen_module. I.e. it should be possible to >=20 > xen_module --type=3DXXX some-module --option1=3DFOO --option2=3Dbar Yes, everything before the filename would be an option to command itself. We have a similar thing with multiboot command. Currently there are no options to xen_*, so no code to handle them. But it's impossible to get any confusion as if you currently specify any of such future options you'll get an error of bad file, so we won't break any compatibility. Do you see any reason to introduce flag-handling code now? Would it be for better error message? --oFuEMO4LamknvE7h4k007GUg2kn23jLLD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREKAAYFAlZEbUgACgkQmBXlbbo5nOvrSAD9G/hny4vn5ct4iccliIYHYxF5 TtKE2W21aTeLUifs8/gA/idSHsyGN0RLAalUMFnrqtwjsT08zhT77SixVxRbSHF7 =dsbo -----END PGP SIGNATURE----- --oFuEMO4LamknvE7h4k007GUg2kn23jLLD--