[U-Boot] Read-only env variables

[Wolfgang Denk]

Dear Joe Hershberger,

In message <AANLkTimqkxOkQeNTy8OcYqNVxNK5rLMoqHoRSnFqQnqk at mail.gmail.com> you wrote:
> On Mon, May 10, 2010 at 1:56 AM, Wolfgang Denk <wd at 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 not
> set, 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

-- 
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
That's the thing about people who think  they  hate  computers.  What
they really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"