[U-Boot] Read-only env variables

[Joe Hershberger]

On Mon, May 10, 2010 at 1:56 AM, Wolfgang Denk <wd at denx.de> wrote:
> Well, we could go for a simple type scheme, something like
>
>        d - decimal number
>        i - IP address
>        m - mac address
>        s - string
>        x - hex number
>        ...

       l - list delimited by ';' (special behavior for setenv)

> plus similarly simple access control codes:
>
>        d - no change except reset to default possible
>        o - one-time setting, no changes afterward
>        r - read-only
>        (none) - unrestricted access
>
> Then we could do something like:
>
> setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr
>
> The only disadvantage is that the meaning of the qualifiers is
> position dependent, but I think this is acceptable for the purposes we
> have in mind.

That seems pretty reasonable.  I think I'd like to see the access
control codes more role based than limitation based.  Such as:

     u - unique board configuration (mac addr, ser#)... set if not
set, default override
     s - script in env var... read only, default
     r - runtime variable (ip addr)... set in env, not saveable to flash.

> I think bitmasks is probably overkill - we probably don't need that
> many options. The scheme above could be extended for more qualifiers
> as well.

I think I will at least use bitmasks to define each of the commands
that are available in the acl env var.  That will make defining new
commands simple.

>> Another thing that would make dealing with the lists in env variables easier
>> would be to support slightly different behavior for setenv...  here's what I
>> have in mind: if an env variable called "myList" contains
>> "varName1;varName2" and you call "setenv myList varName3", then the result
>> is myList contains "varName1;varName2;varName3".  If you then call "setenv
>
> That would be incompatible to existing use. Not a good idea, IMHO.
>
>> myList -varName2", then myList would contain "varName1;varName3".  The
>> behavior would be available in general by having a list variable type (just
>> like numeric or IP addr).  I'm not set on using semi-colons as list
>> delimiters or the "-" to signify remove-from-list in setenv, but those seem
>> natural.  I'm interested if there are any foreseeable issues with those
>> selections or if there are more appropriate options.
>
> What would be your use of such list vatiables?

Specifically for manipulating the acl and any other list that a user
may need.  Because it will self reference and define its type as a
list,

> And what's wrong with
>
>        setenv myList "varName1;varName2"
>        setenv myList "$myList;varName3"
>
> to do the same as above, using only the existing feature set?

There's nothing wrong with that, but the issue is with removal... and
if you are making the behavior special for lists, then this is cleaner
than dereferencing the original list every time.

> OK, the "remove entry" function is not that easy here, but which usage
> do you have in mind that needs that?  I never ran into that before.

Consider the case where a variable is defined as a runtime variable,
but the user would like to change the value and commit that change to
flash.  It would be much more usable if there were a simple way to
remove an element from a list.

>> --0016e640d1748106790486378cdb
>> Content-Type: text/html; charset=ISO-8859-1
>> Content-Transfer-Encoding: quoted-printable
>
> Please stop this.

Apologies.

Best regards,
-Joe