[U-Boot] Read-only env variables

[Joe Hershberger]

On Thu, May 6, 2010 at 4:58 PM, Wolfgang Denk <wd at denx.de> wrote:

>
> You might also go one step further and define variable types -
> numeric, string, MAC addr, IP addr, ...
>
I'm guessing the reason for this being that the value can be validated on
set instead of on use?  I can see some interactive usability benefit to
this.  Also the Linux fw_setenv would be well served with this capability.


> On the other hand I wonder if a compile-time defined, static list is
> such a good idea. Why not putting this list in a variable itself? Then
> users could use this feature to add their own r/o variables, or
> protect already existing definitiins, etc. etc. [Note that you could
> still prevent users from editing the list by including a reference to
> itself.]


This is interesting.  I had considered this my self as an option for items
(such as ipaddr) which some times the user wants to change and save (static
ip) and other times would not like to save (ip set by dhcp).  This would
call for a dynamic configuration for the variables.  Having all of this in
an environment variable seems like it would get cumbersome to use rather
quickly.  I like the elegance of everything being in the env, but I'm not
sure that it's practical, especially if each variable name is assigned a
type and access control.

As I thought more about the implementation, I like the idea of using
bit-masks for each part of the access control that users can OR together in
their board config headers.  Unfortunately, that doesn't play nicely with
initializing default u-boot env variables due to the need to convert the
result of some expression into a string literal in the preprocessor.  I'm
not aware of any way to do that.  That also means that changing the
configuration in the env on the fly is tedious because the user must
remember the masks.  One way around this would be to make the default env
creation routing a bit more fancy and have it generate the env variable at
run-time based on the compiled in masks.

Another possibility that could make things simpler to use at runtime would
be to create a separate env variable for each access control bitmask element
and allow the user to simply add the variable names to those variables.
They get the behavior for each one the name is in.

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
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.


> If we had such a  feature, then all special handling of serial# and
> ethaddr should go away, of course (this would also allow to fix the
> inconsistent behaviour of ethaddr (read-only) versus eth<N>addr
> (writable).
>
I see we're on the same page about cleaning up these one-off behaviors.
Excellent.


> Regarding CONFIG_HAS_UID - I never understood what it was intended
> for, and it is completely undocumented, and davinci_schmoogie and
> MVSMR are the only boards that actually use it. It should be removed
> from common code.
>
I agree.  It really doesn't seem to fit, though it could be made one of the
access control types rather simply.

Best regards,
-Joe