On Thu, May 6, 2010 at 4:58 PM, Wolfgang Denk wd@denx.de wrote:
You might also go one step further and define variable types - numeric, string, MAC addr, IP addr, ...
I'm guessing the reason for this being that the value can be validated on set instead of on use? I can see some interactive usability benefit to this. Also the Linux fw_setenv would be well served with this capability.
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.]
This is interesting. I had considered this my self as an option for items (such as ipaddr) which some times the user wants to change and save (static ip) and other times would not like to save (ip set by dhcp). This would call for a dynamic configuration for the variables. Having all of this in an environment variable seems like it would get cumbersome to use rather quickly. I like the elegance of everything being in the env, but I'm not sure that it's practical, especially if each variable name is assigned a type and access control.
As I thought more about the implementation, I like the idea of using bit-masks for each part of the access control that users can OR together in their board config headers. Unfortunately, that doesn't play nicely with initializing default u-boot env variables due to the need to convert the result of some expression into a string literal in the preprocessor. I'm not aware of any way to do that. That also means that changing the configuration in the env on the fly is tedious because the user must remember the masks. One way around this would be to make the default env creation routing a bit more fancy and have it generate the env variable at run-time based on the compiled in masks.
Another possibility that could make things simpler to use at runtime would be to create a separate env variable for each access control bitmask element and allow the user to simply add the variable names to those variables. They get the behavior for each one the name is in.
Another thing that would make dealing with the lists in env variables easier would be to support slightly different behavior for setenv... here's what I have in mind: if an env variable called "myList" contains "varName1;varName2" and you call "setenv myList varName3", then the result is myList contains "varName1;varName2;varName3". If you then call "setenv myList -varName2", then myList would contain "varName1;varName3". The behavior would be available in general by having a list variable type (just like numeric or IP addr). I'm not set on using semi-colons as list delimiters or the "-" to signify remove-from-list in setenv, but those seem natural. I'm interested if there are any foreseeable issues with those selections or if there are more appropriate options.
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).
I see we're on the same page about cleaning up these one-off behaviors. Excellent.
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.
I agree. It really doesn't seem to fit, though it could be made one of the access control types rather simply.
Best regards, -Joe