[U-Boot] [RFC PATCH v2 4/7] env: Introduce "transient" and "system" access flags

[Bernhard Nortmann]

Hi Joe!

Thanks for chiming in, especially seeing that you have previously worked
on something very similar.

Am 27.11.2016 um 19:53 schrieb Joe Hershberger:
> On Wed, Nov 16, 2016 at 4:29 AM, Bernhard Nortmann
> <bernhard.nortmann at web.de> wrote:
>> "transient" (='t') is like "any", but requests that a variable
>> should not be exported (ENV_FLAGS_VARACCESS_PREVENT_EXPORT).
>>
>> "system" (='S') is meant for 'internal' variables that
> The flags are positional, so 's' is not in use. It seems it would be
> cleaner to use a lower-case 's'.

You're probably right. I think back then I deliberately picked 'S' to avoid
potential confusion (e.g. users specifying "s" when they actuall mean/want
"ss"), as trying to set flags to just "S" would result in an error message.

For precisely that reason I'd actually prefer to find letter(s) that would
not conflict with existing type or access flags, but 'v'olatile seemed
ambiguous / too broad at that time.

>> [...]
> I'm not sure why you are adding "transient" or "volatile" to the
> varaccess. It is an orthogonal property of a variable. This is obvious
> from the fact that you need to add yet another to compose varaccess
> with varlifetime (or something).
>
> I worked on something similar years ago, but never posted an RFC.
>
> http://lists.denx.de/pipermail/u-boot/2010-June/073027.html

That's a very good point. This 'orthogonality' is what actually caused me
to come up with that "transient" vs. "system" idea. I think I got misled
by the way that U-Boot already combined various "access" bit flags, and it
never occured to me to introduce another property with a third flag 
character.
Actually "?av" (any-access, volatile) and  "?rv" (read-only, volatile) would
represent my intent perfectly well.

I also like your "auto-volatile" concept a lot (i.e. resetting the volatile
nature on setenv by the user). To stay unambiguous ('a' = "any" access),
maybe this could be tagged 't'emporary. We'd also need a default letter for
the lifesspan flag, possibly 'n'ormal?

The temporary (= auto-volatile) flag would also nicely save use from the 
need
to have users fumble with "setenv .flags", and the quirks involved.

Implementing this means some refactoring / a major overhaul of this RFC
series, but I think it could be well worth that. I'll definitely give it
a try when I find some time.

Regards, B. Nortmann