Dear Joe Hershberger,
In message AANLkTimqkxOkQeNTy8OcYqNVxNK5rLMoqHoRSnFqQnqk@mail.gmail.com you wrote:
On Mon, May 10, 2010 at 1:56 AM, Wolfgang Denk wd@denx.de wrote:
Well, we could go for a simple type scheme, something like
d - decimal number i - IP address m - mac address s - string x - hex number ...l - list delimited by ';' (special behavior for setenv)
Don't do this. ';' has a clear meaning. Using it for other purposes
That seems pretty reasonable. I think I'd like to see the access control codes more role based than limitation based. Such as:
u - unique board configuration (mac addr, ser#)... set if notset, default override s - script in env var... read only, default r - runtime variable (ip addr)... set in env, not saveable to flash.
This is most probably less flexible and more cumbersome to use. It's easier to define what exactly you want to do (don't allow over- writing) that finding a role that happens to include this behaviour. Think also about the end user who wonders why variable "foo" is considered to be a "unique board configuration" when all you wanted is to apply certain behaviour.
What would be your use of such list vatiables?
Specifically for manipulating the acl and any other list that a user may need. Because it will self reference and define its type as a list,
Why would that be needed?
See my example above:
setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr
[Implementation note: the implementation should allow for and ignore repeated or trailing ',' separators - i.e. something like "delay:d,,,address:a,ipaddr:i,ethaddr:mo,,serial#:sr,," should work as well. Reason: see below about incremental building.]
There's nothing wrong with that, but the issue is with removal... and if you are making the behavior special for lists, then this is cleaner than dereferencing the original list every time.
Well, we have the editenv command, which makes editing pretty easy. I fear/feal that adding lists is (1) not really needed and thus most likely more overhead than benefit, and (2) holds a lot of potential for causing confusion and conflicts.
We don't have lists vailables in bash either (or do we?)
OK, the "remove entry" function is not that easy here, but which usage do you have in mind that needs that? I never ran into that before.
Consider the case where a variable is defined as a runtime variable, but the user would like to change the value and commit that change to flash. It would be much more usable if there were a simple way to remove an element from a list.
What to you mean by "runtime variable" or by "change to flash"? I don;t understand what these terms are supposed to mean. As mentioned before, "editenv" seems a pretty straightforward way to edit the settings.
I feel we should try to make this not overly complicated - don't add bells and whistles without real need. Also keep in mind that a lot of power results from being able to dynamically build such settings from smaller blocks.
I can imagine scripts that run things like
setenv acl "$acl_net,$acl_hw_id,$acl_foo,$acl_bar"
Best regards,
Wolfgang Denk