[U-Boot] Read-only env variables

[Wolfgang Denk]

Dear Joe Hershberger,

In message <AANLkTil4TOC4Tmh0nZQXI8ahHT2LnwOmKLpsta_LFqrA at mail.gmail.com> you 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.

Right, that was my intention.

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

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

plus similarly simple access control codes:

	d - no change except reset to default possible
	o - one-time setting, no changes afterward
	r - read-only
	(none) - unrestricted access

Then we could do something like:

setenv acl delay:d,address:a,ipaddr:i,ethaddr:mo,serial#:sr

The only disadvantage is that the meaning of the qualifiers is
position dependent, but I think this is acceptable for the purposes we
have in mind.

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

I think bitmasks is probably overkill - we probably don't need that
many options. The scheme above could be extended for more qualifiers
as well.

> 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

That would be incompatible to existing use. Not a good idea, IMHO.

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

What would be your use of such list vatiables?

And what's wrong with 

	setenv myList "varName1;varName2"
	setenv myList "$myList;varName3"

to do the same as above, using only the existing feature set?

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.

> --0016e640d1748106790486378cdb
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable

Please stop this.

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
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall