On Wed, Jul 1, 2020 at 4:36 PM Lennart Poettering <mzerq...@0pointer.de> wrote:
> On Mi, 01.07.20 13:14, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
> > I'm not sure if this is completely fair, it's true that GRUB's blscfg
> > module diverged from the spec by adding support for variables but it
> > can also parse BLS snippets that follow the spec verbatim.
> You missed the point of the whole spec:
> the spec was that every party which interfaces with boot loaders knows
> where to find and how to deal with boot loader entries, and to make
> them as simple that every party can easily parse them and make sense
> of them, and share them. This means that many parties can *read* them
> without trouble and *drop-in* them without trouble either.
> By turning them into a programming language you broke that contract,
> because suddenly your files cannot be read without any embedded
> tremplating language interpretor. You own your files, but everyone
> else cannot make sense of it.

I've already acknowledged that using variables in the options field
was a mistake, since that is a known field according to the spec and
so it broke the contract. And also mentioned that this was already
fixed in F33, other boot loaders should now be able to parse the BLS
snippets (assuming that ignore other fields only relevant to GRUB for
boot entries auth).

> Note that the spec has extension points (i.e. it's permissible to add
> new fields without this breaking the spec), but turning it into a
> programming lnaguage is waaaay outside of it...

I wouldn't consider adding variable expansion support to turn them
into a programming language. But yes, you are right that we diverged
from the spec and that caused issues to other bootloaders (i.e: I had
this same conversation with the LinuxBoot folks).

But rather than keep pointing out what we got wrong, I would prefer to
figure out how to make the GRUB implementation to align with the spec
while still supporting all the features that are available in a
non-BLS configuration. This could also allow to have a single
kernel-install plugin instead of having specific plugins for
GRUB/Petitboot and zipl.

Best regards,
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to