From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 12mJHC/EYV+0fwAA0tVLHw (envelope-from ) for ; Wed, 16 Sep 2020 07:52:15 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id YG12Fi/EYV84QgAAbx9fmQ (envelope-from ) for ; Wed, 16 Sep 2020 07:52:15 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D516F940142 for ; Wed, 16 Sep 2020 07:52:14 +0000 (UTC) Received: from localhost ([::1]:39312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kISEf-0005Qz-Tc for larch@yhetil.org; Wed, 16 Sep 2020 03:52:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kISEU-0005PK-AK for guix-patches@gnu.org; Wed, 16 Sep 2020 03:52:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:49795) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kISEU-0001O0-1X for guix-patches@gnu.org; Wed, 16 Sep 2020 03:52:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kISEU-0004WZ-0W for guix-patches@gnu.org; Wed, 16 Sep 2020 03:52:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#41011] [PATCH] gnu: grub: Support for network boot via TFTP. Resent-From: Efraim Flashner Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 16 Sep 2020 07:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41011 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Stefan Cc: Danny Milosavljevic , 41011@debbugs.gnu.org Received: via spool by 41011-submit@debbugs.gnu.org id=B41011.160024272017383 (code B ref 41011); Wed, 16 Sep 2020 07:52:01 +0000 Received: (at 41011) by debbugs.gnu.org; 16 Sep 2020 07:52:00 +0000 Received: from localhost ([127.0.0.1]:33108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kISES-0004WI-0s for submit@debbugs.gnu.org; Wed, 16 Sep 2020 03:52:00 -0400 Received: from flashner.co.il ([178.62.234.194]:53700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kISEP-0004W2-16 for 41011@debbugs.gnu.org; Wed, 16 Sep 2020 03:51:58 -0400 Received: from localhost (unknown [31.210.181.177]) by flashner.co.il (Postfix) with ESMTPSA id 742B740037; Wed, 16 Sep 2020 07:51:50 +0000 (UTC) Date: Wed, 16 Sep 2020 10:51:17 +0300 From: Efraim Flashner Message-ID: <20200916075117.GE19874@E5400> References: <9AAFEFF4-8ACE-4C95-975F-67C3F4FDAF81@vodafonemail.de> <20200906163559.1b56c36f@scratchpost.org> <45F0D825-F888-42E9-BDAE-7BB6FA010A6E@vodafonemail.de> <20200909003732.5c401932@scratchpost.org> <20200914065911.GB1717@E5400> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vJguvTgX93MxBIIe" Content-Disposition: inline In-Reply-To: X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -2.61 X-TUID: ni7IkWcZDKep --vJguvTgX93MxBIIe Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 15, 2020 at 10:28:53PM +0200, Stefan wrote: > Hi Efraim! >=20 > >> + (boot-efi-link (match system > >> + (("i686" _ ...) "/bootia32.efi") > >> + (("x86_64" _ ...) "/bootx64.efi") > >> + (("arm" _ ...) "/bootarm.efi") > >> + (("armhf" _ ...) "/bootarm.efi") > >> + (("aarch64" _ ...) "/bootaa64.efi") > >> + (("riscv" _ ...) "/bootriscv32.efi") > >> + (("riscv64" _ ...) "/bootriscv64.efi"))) > >=20 > > Don't forget the fall-through case, even if it's just > > ((_ ...) "/bootTODO.efi") >=20 > There was a contradicting remark by Danny: >=20 > > The major advantage of using "match" is its failure mode. If the thing= matched > > on is not a list (for some unfathomable reason) or if the first element= is not > > matched on (!) then you get an exception--which is much better than doi= ng weird > > unknown stuff. >=20 > Actually I would prefer an error here as well. Imagine a successful =E2= =80=98guix system init=E2=80=99 silently creating a bootTODO.efi. Booting t= hat system will certainly fail and someone will have a hard time to figure = out that the generated bootTODO.efi is the reason. >=20 My concern is more for architectures which aren't on the list having unfortunate errors while doing something unrelated. Another option then I suppose would be ((_ ...) #f) It should still fail if you try to use it but there's still a code path for, say, ppc64el. I like the #f idea better than bootTODO.efi. > >> + (efi-bootloader (string-append (match system > >> + (("i686" _ ...) "i386-efi") > >> + (("x86_64" _ ...) "x86_64-e= fi") > >> + (("arm" _ ...) "arm-efi") > >> + (("armhf" _ ...) "arm-efi") > >> + (("aarch64" _ ...) "arm64-e= fi") > >> + (("riscv" _ ...) "riscv32-e= fi") > >> + (("riscv64" _ ...) "riscv64= -efi")) > >> + "/core.efi"))) > >=20 > > With the fall-through case here, can this be changed to > > (("i686" _ ...) "i386-efi") > > (("aarch64" _ ...) "arm64-efi") > > (("riscv" _ ...) "riscv32-efi") > > ((_ ...) (string-append (first > > (string-split > > (nix-system->gnu-triplet > > (or (%current-system) > > (%current-target-system))) > > #\_)) > > "-efi")) I re-noticed that system is passed above so my code block could be a bit more contained ((_ ...) (string-append (first (string-split (nix-system->gnu-triplet system) #\_)) "-efi")) >=20 > There was a contradicting remark by Danny, which applies to the first par= t as well: >=20 > > Also, I have a slight preference for greppable file names even when it'= s a > > little more redundant >=20 > I understand your point in generating the arch part. I also understand th= e usage of (nix-system->gnu-triplet) to convert armhf to arm. I also think = the risk is low that the first part raises no error and this part is doing = something wrong without raising an error, too, leading to a not booting sys= tem. So having a default here seems fine to me. >=20 > However, Danny=E2=80=99s argument is convincing, too. And keeping this bl= ock similar to the first block eases the understanding, at least mine. My f= irst thought seeing your suggestion was: =E2=80=9CWhy does this block need = to be different from the other and what is this code doing differently?=E2= =80=9D >=20 > What do you think? >=20 The benefit is that there's less chance of typoing a mistake in the code, either when writing it or when editing it later. There's also the benefit again of not dismissing architectures which are currently not listed in the list. For something greppable, I don't really have a counter argument. Perhaps a hand-wavey "code correctness" of reusing macros. For unsupported architectures, ((_ ...) #f) again would work to make sure there is at least a code path which would definitely fail if someone tried to use it. That's my primary concern. >=20 > Bye >=20 > Stefan >=20 Thanks --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --vJguvTgX93MxBIIe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl9hw/IACgkQQarn3Mo9 g1GYlRAAmDWgGgK5tBj+7DeNHaqgqqdGGi1hzb8i6Due9jyJ6b/2o3EeOaYCkbQ/ 7oLhNAH1zbqzftH8Uev7XcZEDBak62Zpld7Y7Optv9zC/hBgaVe/vkTkeYPCATll lxLdHTre4xbfyzLV+0fx+QEDn78CtIRylDt03D2AlYvGXivb4W6DvMv0nzzd9Hmm xDh/a8kz5uSf8Yg9GRl1C8bgwphKjJLLtB+bHFxzZ4hfH0ifVoev7gv6XcOOqCZD U0a98bDwtl3+8inNqpwTKf3cMfar7rFCSfyH+1TVX9rip+YDkcxY3SAabPimeILY IxJI3U5lCwjD4KPAYQJcoVe9Re072U8Az0xjUOHSOCsQfh4vyiHYgQE+LtK4GBDO t+5TbDbtwO9gTww5r+FDB2VphYccxRcqRKv5kYiPwzIcQACjye6ayiv7F+qKZVew LkntuZVdFmmh38ypdD7qey/w4H4WpxdUv4fdcm1jkb4WkZ8BCIvW1tkM0u4hLa2H 7kpcDgqrcGUkL9qhbChS2yacpaSkzcjKN/HgqxkQH9iO8b0OFqzirLCxsEx5DR6o 2iQNPDBdxkshbHffTm+u2ynOO+ECCdD28qb2dX+4H64T2i7T56Z26AHLHzoAnFYP S6xL6i0wBNjfwvv+AoX3rHYv46OsVPL6cE47uCHIr+/i+TJWQ9s= =E7hx -----END PGP SIGNATURE----- --vJguvTgX93MxBIIe--