From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: gnu/system/u-boot.scm Date: Thu, 6 Oct 2016 10:12:23 +0200 Message-ID: <20161006101223.389e56ac@scratchpost.org> References: <20160721223501.3a989d55@scratchpost.org> <877fc815wg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bs3nC-0004AY-0d for guix-devel@gnu.org; Thu, 06 Oct 2016 04:12:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bs3n5-000123-U1 for guix-devel@gnu.org; Thu, 06 Oct 2016 04:12:36 -0400 In-Reply-To: <877fc815wg.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: guix-devel Hi, so now that all of it works, I'd like to propose to change how it's done co= mpletely (muhahaha). Ludo wrote: > 2. (gnu system) should dispatch to either =E2=80=98grub-configuration-f= ile=E2=80=99 or > =E2=80=98u-boot-configuration-file=E2=80=99 depending on whether the= config > contains a =E2=80=98grub-configuration=E2=80=99 or a =E2=80=98u-boot= -configuration=E2=80=99 object. I think it would be better if (gnu system) installed *both* the grub config= uration file *and* the u-boot configuration file. The main advantage would be if the user already had a bootloader, it would = be possible to leave the bootloader form off completely in /etc/config.scm = . The bootloader configurations would still be updated and the right one sh= ould be picked up by the bootloader (Note: Libreboot checks for "grub/libre= boot_grub.cfg"; U-Boot checks for "extlinux.conf" (and others); Grub checks= for "grub/grub.cfg"). (This is in order to support bootloaders that are in ROM or Flash, mostly. = One usually doesn't update those [I guess it doesn't hurt if you install an= other dummy bootloader on disk, though]. VMs also don't need a bootloader -= but do need the config) Another advantage would be that there would be no "u-boot-configuration" ob= ject and the user would not have to choose between it and "grub-configurati= on". It would be all the same configuration object (by then erroneously cal= led "grub-configuration" - which we can keep for backward compatibility I g= uess).=20 The programs "grub-install" and (future) "u-boot-install" expect a fixed fi= lename for their config file - so they are not confused by it either. So th= at's neutral :) There's no need to provide two different configuration objects (they are al= most completely the same - save the output procedure). I'd say it's a maint= enance advantage not to have them. And the only disadvantage would be that the bootloader installation procedu= re would have to check whether "grub-install" exists. If it does, invoke it= . Otherwise invoke "u-boot-install". Essentially success would be if either= invocation succeeded (that is: the respective executable was found). [We c= ould also add a "grub-install" executable to the u-boot packages if we want= ed to avoid that] grub-configuration would need just one new field "installer" which would li= st the package of the bootloader-to-install, if any.=20 And there would need to be a new procedure "grub-configuration-files" with = multiple files *instead* of "grub-configuration-file". (Think of "grub" as = "bootloader" in this name) operating-system-grub.cfg would also need to return multiple files (and may= be their target names, too?). If we wanted to be backward compatible (probably), we could install grub if= there was no field "installer" specified. (Although in a non-backward-comp= atible world I'd prefer if it installed no bootloader in that case - it wou= ldn't even have any fallout if it now didn't install the bootloader on exis= ting systems) What do you think? If we want to do it, could you help me write "grub-configuration-files" ? grub-configuration-file seems to use gexp->derivation at the end (which pro= bably form a store monad). Can I just return a Scheme list of those or how = would this work? Do I then need to carry the target filename in a pair? "grub.cfg" is a gc root. How would this need to be adapted? If we later wanted to modify GuixSD to switch over to special configuration= s (although I don't see why we would), we can still do that without backwar= d compat problems. So this wouldn't lock us in.