From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fI8wl-0000Yt-N1 for guix-patches@gnu.org; Mon, 14 May 2018 04:35:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fI8wg-0000z8-RQ for guix-patches@gnu.org; Mon, 14 May 2018 04:35:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:53572) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fI8wg-0000yz-NU for guix-patches@gnu.org; Mon, 14 May 2018 04:35:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fI8wg-0001Nh-Fz for guix-patches@gnu.org; Mon, 14 May 2018 04:35:02 -0400 Subject: [bug#31416] [PATCH 3/4] bootloader: Add make-u-boot-bootloader. Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20180511143515.23435-1-dannym@scratchpost.org> <20180511143652.26935-1-dannym@scratchpost.org> <20180511143652.26935-3-dannym@scratchpost.org> <87603rnbi5.fsf@gnu.org> <20180513125925.66a91367@scratchpost.org> Date: Mon, 14 May 2018 10:34:20 +0200 In-Reply-To: <20180513125925.66a91367@scratchpost.org> (Danny Milosavljevic's message of "Sun, 13 May 2018 13:03:43 +0200") Message-ID: <87in7qbppv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Danny Milosavljevic Cc: 31416@debbugs.gnu.org Hello Danny, Danny Milosavljevic skribis: >> (define-record-type >> (board name triplet installer) >> =E2=80=A6) >>=20 >> Thoughts? > > The idea of make-u-boot-bootloader (and os-with-u-boot) was that it would= free > us from having to play whack-a-mole regarding u-boot (except for the > installation methods of which there are much fewer than boards or chip mo= dels) > and also free the user from having to know anything but the board name. > > With your idea it would mean that we'd have to carry a huge list of s, > defining the board and architecture and installer, right? (or I guess the > user would have to create it on-the-fly) > > That's exactly what I was trying to avoid :) Oh I see, especially the 1.2K boards vs. 86 SoCs! Then perhaps =E2=80=9Cboard=E2=80=9D is not the right abstraction; maybe would make more sense? Either way, my point was that it would be nice to have some abstraction to clearly specify things, and then use that as an input to construct both the U-Boot package and its configuration. Or do you think enumerating the SoCs would still be too painful? In that case, some auto-guessing might be the right choice, but in general, I think it should be a last resort. :-) Thanks, Ludo=E2=80=99.