bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

[Danny Milosavljevic]

Hi Mathieu,

On Wed, 31 May 2017 09:23:27 +0200
Mathieu Othacehe <address@hidden> wrote:

> +(define-record-type* <menu-entry>
...
> +  (initrd          menu-entry-initrd))     ; file name of the initrd as a 
> gexp

For another future patch:  Hmm, should we make this optional?  I didn't have an 
initrd for many years.

> --- a/gnu/bootloader/extlinux.scm
> +++ b/gnu/bootloader/extlinux.scm
> @@ -37,7 +37,8 @@
>  corresponding to old generations of the system."
>  
>    (define all-entries
> -    (append entries (bootloader-configuration-menu-entries config)))
> +    (append entries (map menu-entry->boot-parameters
> +                         (bootloader-configuration-menu-entries config))))

Since we have menu-entry as a public datatype now, should we maybe use 
menu-entries for all the bootloader stuff ?  I think this would be easier to 
maintain because boot-parameters is a serialized format we can't easily change 
(because it's stored into a "parameters" file per generation, and generations 
can't ever be deleted).

In that case maybe it could rather be boot-parameters->menu-entry for the other 
(i.e. the GuixSD) entries instead of this.

> +  (define (boot-parameters->gexp params)

Maybe rather menu-entry->gexp and take a menu-entry ?

> +(define (menu-entry->boot-parameters menu-entry)

Then we'd have menu-entry->boot-parameters *and* boot-parameters->menu-entry 
which is usually a dead giveaway that we are doing something strange.  It would 
make it either a 1:1 map or lose data on the roundtrip, both of which are weird.

That's why I think if we have public <menu-entry> records anyway now, let's use 
them for the bootloader stuff throughout.

WDYT?