[U-Boot] Read-only env variables

[Joe Hershberger]

On Mon, May 10, 2010 at 3:43 PM, Wolfgang Denk <wd at denx.de> wrote:
>>        l - list delimited by ';' (special behavior for setenv)
>
> Don't do this. ';' has a clear meaning. Using it for other purposes

Fair enough... ',' then.

>> 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.
>
> This is most probably less flexible and more cumbersome to use.  It's
> easier  to  define  what  exactly  you  want to do (don't allow over-
> writing) that finding a role that happens to include this  behaviour.
> Think  also  about  the  end  user  who wonders why variable "foo" is
> considered to be a "unique board configuration" when all  you  wanted
> is to apply certain behaviour.

The primary reason for wanting this sort of comes back to the reason I
wanted bitmasks in the first place.  I want to be able to mix certain
access control attributes for different variables.

I've added a command called "defaultenv" which comes in really handy
in practice here.  Basically what it does is revert everything in
memory to a default env except for certain (currently hard coded)
variables such as ethaddr and serial#.  This means that if I rebuild
and change a script or boot command, my people can simply load the new
u-boot and run "defaultenv;saveenv" to get the updated scripts but not
have to redefine all the board unique variables like they would if
they just erased their env sectors.  I'd like to specify that a
variable should be preserved on reverting to default env independent
of being read-only or not.  Perhaps you would prefer to have each
permutation defined as a sum of attributes instead of a role.  It's
the same thing with a different name.

>> > 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,
>
> Why would that be needed?
>
> See my example above:
>
>        setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr

The idea was that if you wanted to remove "ethaddr:mo" from the list
for instance, you could do so without dealing with the rest of the
items in the list.  See below.

> [Implementation note: the implementation should allow for and ignore
> repeated or trailing ',' separators - i.e. something like
> "delay:d,,,address:a,ipaddr:i,ethaddr:mo,,serial#:sr,," should work
> as well. Reason: see below about incremental building.]

I agree.  It will be tolerant of this.

> Well, we have the editenv command, which makes editing pretty easy.
> I fear/feal that adding lists is (1) not really needed and thus most
> likely more overhead than benefit, and (2) holds a lot of potential
> for causing confusion and conflicts.

I haven't used the editenv command, so I'll play with that a bit.  It
sounds like it will make my concern about removal less of an issue.
I'll try it and see how usability feels.

> We don't have lists vailables in bash either (or do we?)

Not that I'm aware of.  Arrays, yes, but that's not what I'm going for here.

>> > 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.
>
> What to you mean by "runtime variable" or by "change to flash"? I
> don;t understand what these terms are supposed to mean.  As mentioned
> before, "editenv" seems a pretty straightforward way to edit the
> settings.

What I'm referring to here is being able to specify a variable as r/w
while running in u-boot, but that that value will not be written to
flash.  If the value was defined in flash, then the existing value in
flash will be retained when saveenv is called.  Again, I'm considering
the case with "ipaddr" and family.  If the user wishes to change the
static IP, then that change should be written to flash.  If the user
wishes to use dhcp to configure all the network settings, those
settings should not be saved to flash (and then used as though they
were static settings).  Currently if you use dhcp and then want to
save some other change in the env, you save all the dhcp settings and
the next time the board is powered, you use an address that you have
no lease for and probably conflict with another machine.

> I feel we should try to make this not overly complicated - don't add
> bells and whistles without real need. Also keep in mind that a lot of
> power results from being able to dynamically build such settings from
> smaller blocks.

I also don't want it to be complicated, but I'd like it to cover the
use cases that I'm up against at the moment in a relatively user
friendly way.  I feel like we are close to a solution.

> I can imagine scripts that run things like
>
>        setenv acl "$acl_net,$acl_hw_id,$acl_foo,$acl_bar"

That sounds great.  I also envision making part of the acl
unchangeable and part of it changeable.  That would be done by making
the the acl reference itself as read-only and also contain a
dereference such as:
"acl=$acl_rw,acl:sr,ipaddr:i,ethaddr:mo,serial#:sr".  You could then
change the value of acl_rw at runtime but not the value of acl.

One thing I've noticed that I don't quite understand is how you can
add a '$' to a variable's value from the command line.  If I escape it
with a '\', the '\' sticks around in the value of the variable, but if
I don't escape it, then the '$' dereferences in the setenv.  Seems
like a bug to me.  The '\' should not end up in the value of the var
when used in setenv to escape the '$'.

Best regards,
-Joe