[U-Boot] Read-only env variables

[Wolfgang Denk]

Dear Joe Hershberger,

In message <AANLkTinCGpjd6x_Plgm4nkATlRNht83KFC8Xk2MNIK8d at mail.gmail.com> you 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?

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

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

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

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
CAUTION:  The Mass of This Product Contains the Energy Equivalent  of
85 Million Tons of TNT per Net Ounce of Weight.