Dear Joe Hershberger,
In message h2j4b538921004271907naebeb396t3928a9f41cc32046@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