On Wed, Jul 1, 2020 at 4:36 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > On Mi, 01.07.20 13:14, Javier Martinez Canillas (javier@xxxxxxxxxxxx) 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, Javier _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
