On Fri, Apr 27, 2018 at 09:58:07AM +0100, Leif Lindholm wrote:
This is the "priority" statement I think it problematic as discussed on todays call. I think Boot### should be followed if present but boot firmware writers should be cautioned not to hard code stupid stuff into them. (The tricky bit will, of course, be comming up with a definition of stupid stuff. A list of bad examples may be the best way to do this.)
Yes. This statement was based on my incorrect assumption that we were permitting systems without any persistent variable storage in the first revision of the spec. (As opposed to only systems that did not provide persistent variable storage at runtime.)
To be honest, I'm not sure there was 100% argeement either way on yesterday's call but we're definitely zooming in a bit. If only because there were too many "let's leave aside level 0/1 for the time being" to be sure where this all fits.
However it seems to be me to be *really* beguiling to combine:
1. A LoaderEntryOneShot set variable implementation that survives a warm boot
2. Support persistent variable storage from UEFI applications
3. (Almost) normal handling of boot variables (assume we still want fallback to removeable media mode if the other boot options fail?).
Seems like that would make it relatively easy (or at the least possible) to add special EBBR equivalents of efibootmgr/efivar and allow distro install flows to work like (almost) normal.
However, as I said above, I'm not sure if we are talking level 0 or level 1 here?
Daniel.