Dear Takahiro,
In message 20190626052624.GR6610@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 ...)
(assuming GUID for UEFI variable)
- to allow arbitrary type of key instead of a string of name
- to allow arbitrary type of value instead of a printable string
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