Dear Takahiro, In message <20190626052624.gr6...@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: w...@denx.de God made the integers; all else is the work of Man. - Kronecker _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
