[U-Boot] Read-only env variables

[Wolfgang Denk]

Dear Joe Hershberger,

In message <h2j4b538921004271907naebeb396t3928a9f41cc32046 at mail.gmail.com> you wrote:
> 
> I see u-boot supports readonly serial# and ethaddr, but I have a few
> other variables that I need to be read-only.  I'm planning to
> implement a generic list of variables that cannot be changed or
> deleted.

Good idea, and thanks in advance!

> I'm interested to know what sort of specification people would find
> most appropriate.  My current thought is to follow the same delimiter
> as the env itself, i.e. null separated list with double null
> terminator.  This list would then be defined in the board config
> header.  It also seems that you should be able to specify simple
> access rules for each variable name perhaps using "=<val>" after each
> var name where <val> could have constants (probably numbers for
> performance, but could be string literals) to define modes.  Right now
> I'm thinking read-only, create-only, change-default, and change-only
> (i.e no delete) are the modes that make sense.

You might also go one step further and define variable types -
numeric, string, MAC addr, IP addr, ...

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

> I'm also interested if anyone would be opposed to simply using this
> new specification of readonly vars to implement the serial# and
> ethaddr protection.  The CONFIG_HAS_UID is a bit odd... should that be
> available in general for read-only vars?

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

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.

Sergey, Andre - comments?

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
You get a wonderful view from the point of no return.
                                    - Terry Pratchett, _Making_Money_