[U-Boot] Read-only env variables

[Joe Hershberger]

On Tue, Jun 22, 2010 at 4:18 PM, Wolfgang Denk <wd at denx.de> wrote:
>> > Taking this one step further, we should then also rename "editenv"
>> > into "env edit".
>>
>> Why rename one existing command?  Why not rename askenv and the rest?
>> I don't think I would rename any of them or I would have a clear
>> separation and reason for renaming some and not others.
>
> Did you in any way start working on this?

I did not rename the commands yet... though I did implement 2/3 of the
ACL.  I never head back on which parts of the env handling should be
renamed and why.

> FYI: I'm in the process of a bigger rewrite of the envrionment
> handling code, which will, among other things, perform such a
> renaming (keeping the old names in place, for compatibility, of
> course).

So this means all aspects of the env handling would be under "env *"
including such things as printenv and setenv?  I like this so long as
the current commands remain for compatibility.

>> > But this is IMHO wrong. The ACl should describe properties, i. e. if a
>> > variable can be written or not etc.  It should NEVER try to define how
>> > the user deploys the properties of a variable.
>>
>> It's a tool for the user to implement his chosen policy.  Instead of
>> writing a script to keep track of variables that have changed (that he
>> doesn't want to save) and having to call saveenv through a wrapper
>> script to process that list, it could be as simple as him adding that
>> to the ACL.
>
> I think I'll address this situation from another side; in my new code
> you will be able to export and import envrionment data; this way you
> can for example save and restore snapshots of your environment
> settings, and switch between several configurations easily. Also, you
> can build your configuration by incrementally adding sets of
> definitions.

That sounds interesting.  Is there another thread where you've gone
into detail about this?

>> I've implemented the acl for type and access specification.  It
>> currently looks like this:
>>
>> The first char in the attributes for a var in the acl is the type.  It can be:
>>
>>     s - string (default)
>>     d - decimal
>>     x - hexadecimal
>>     b - boolean
>>     i - ip address
>>     m - ethernet mac address
>
> You might want to add 'p' for pointers.

How is this different than hexadecimal or decimal?  What would the
validation entail?

>> I'm envisioning a third char in the attributes that is the lifetime.  It can be:
>>
>>     p - precious (not removed on env default)
>>     v - volatile (not saved to flash)
>>     a - auto-volatile (not saved to flash, auto-cleared by setenv from
>> command line)
>
> I did not get the concept of "auto-volatile". Please explain once
> more.

I'll try to make it more clear with an example...  take ipaddr for
instance.  Your ACL has configured the ipaddr as "auto-volatile".
Your static IP address is stored in flash in ipaddr.  You boot and
decide you want DHCP, so you run "dhcp" to assign the ipaddr variable.
 You save your environment and the IP address that the DHCP server
gave you is not saved in the flash, it is only used for network
communication during this session.  The next time you boot, you get
your static IP back, since it was not overwritten in your flash.  You
then device that you would like to change your static IP address
setting.  When you call setenv some the command prompt (or a script),
the "auto-volatile" setting is removed from the ipaddr variable in the
ACL (the acl in RAM, not flash) which gives it the default behavior
that all variables have now.  Now when you save your environment, the
new ipaddr setting is saved into flash and available he next time you
boot.

>> I'm also interested if you think it should be a compile time option to
>> support the ACL at all or if it should be added as a first class
>> citizen to permanently take the place of the curent hard-coded
>> behaviors.  I currently have it disabled at compile time (in u-boot,
>> not fw_env), but I also have not removed the other options it could
>> replace.
>
> I think we should make this a compile time option - and if it was for
> the unavoidable additional memory footprint.

So that means we should not remove the current ethaddr and serial#
write protection.

Best regards,
-Joe Hershberger