[U-Boot] efi_loader: implementing non-volatile UEFI variables

[Wolfgang Denk]

Dear Takahiro,

In message <20190626052624.GR6610 at linaro.org> you wrote:
>
> > See above.  If you think small (and go for minimal coding efforts),
> > just add a UEFI flag now to provide a UEFI context.  If tomorrow
> > someone needs a FOO context, add a FOO flag.  We did not really need
> > such context based variable handlint for the last 2 decades, so we
> > can probably go on like this for a couple of years.
>
> In the decades, there came out no new FOO context other than UEFI,
> so it is unlikely that you will see yet another context for next
> couple of years.

I fully agree.

> It is good news to me. I thought that a "single" storage
> was the point.

No.  The current implementation of persistent storage for the
environment has grown historically. In the beginnign we had just a
single copy; later a redundant copy got added. Storage was defined
by static (compile time) selection of the driver and offsets for the
two copies in that device.  And there was/is support only for oine
such copy.

In the mean time, we have DM, and we can / could attach multiple
copies of the environment. We could handle environment blobs from
several devices, for example in a hierarchical way - say, you start
with a standard version of the environment, and when device XXX is
present it is checked if it holds an environment blob (say, a distro
specific set of environment settings), which then gets loaded. Etc.

> Depending on the nature of "context," we may want to have
> different storage devices for different contexts.

This is certainly possible.  It may make sense to make this a
configurable option, whether you want a "classic" envionment share
for all types, or separate storage for each "context".

> So overall, I basically agree with your proposal, but still need
> some more thinkings.
>
> * two new terms
>   - interface (I prefer this over context now): uboot or uefi for now

I'd prefer context here.  Interface my make more sense fromt he UEFi
point of view, but I see other use cases that will use the normal,
U-Boot set of commands / functions to manipulate the variables in
their "context".  Interface suggests that there is another API,
which may be true for UEFI, but not generally.

>   - variable attribute: volatile(/non-volatile) (and autosave if appropriate)
>     some attributes may be interface-specific and expandable in future

Agreed.  For now we can just add to the existing flags (as this
helps to keep the code small).  If there are new ideas / use cases
that require more complex atributes, this can be extended.  Also, I
think we can store all "contexts" in a common hash table, and only
make the import / export / lookup routines respect the new flags /
contexts.

> * extend existing env-related interfaces
>   - accept one or two additional parameters, interface and/or attribute

Agreed.

We also should define a (documented) set of rules, for example for
mixed storage - i. e., if I run a plain "env save", this would only
save the U-Boot environment, but not the UEFI context? 

> * (not sure yet) extend hash functions(hsearch_r ...)
>   - to allow arbitrary type of key instead of a string of name
>   - to allow arbitrary type of value instead of a printable string
>   (assuming GUID for UEFI variable)

I'm not sure if this is worth the effort. Binary data can be
stringified easily.

> * add CONFIG_ENV_xxx's to specify dedicated storage device for each interface

We should be careful not to make this static again.  it makes sense
to be able to configure only the needed drivers / handlers that are
actually supported / used on a board - say, we support "contexts" in
SPI NOR, on SDCard, and on eMMC.  The rest should be flexible - even
if there are default locations it would be nice to be able to
read/write the U-Boot anvionment or the UEFI data to any of these
devices.

> Does this meet your requirements?

Sounds good :-)  Thanks!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God made the integers; all else is the work of Man.       - Kronecker