Re: gnu/system/u-boot.scm

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi,

so now that all of it works, I'd like to propose to change how it's done completely (muhahaha).

Ludo wrote:
>   2. (gnu system) should dispatch to either ‘grub-configuration-file’ or
>      ‘u-boot-configuration-file’ depending on whether the config
>      contains a ‘grub-configuration’ or a ‘u-boot-configuration’ object.

I think it would be better if (gnu system) installed *both* the grub configuration 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 should be picked up by the bootloader (Note: Libreboot checks for "grub/libreboot_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 another 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" object and the user would not have to choose between it and "grub-configuration". It would be all the same configuration object (by then erroneously called "grub-configuration" - which we can keep for backward compatibility I guess). 

The programs "grub-install" and (future) "u-boot-install" expect a fixed filename for their config file - so they are not confused by it either. So that's neutral :)

There's no need to provide two different configuration objects (they are almost completely the same - save the output procedure). I'd say it's a maintenance advantage not to have them.

And the only disadvantage would be that the bootloader installation procedure 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 could also add a "grub-install" executable to the u-boot packages if we wanted to avoid that]

grub-configuration would need just one new field "installer" which would list the package of the bootloader-to-install, if any. 

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 maybe 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-compatible world I'd prefer if it installed no bootloader in that case - it wouldn't even have any fallout if it now didn't install the bootloader on existing 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 probably 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 configurations (although I don't see why we would), we can still do that without backward compat problems. So this wouldn't lock us in.