Re: gnu/system/u-boot.scm

[Danny Milosavljevic]

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.