On Tue, Jun 22, 2010 at 4:18 PM, Wolfgang Denk wd@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