Dear Joe Hershberger,
In message <aanlktimi9fwmiakkvm0rvgwsp5_uhhhtutalz9dbx...@mail.gmail.com> you
wrote:
>
> 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.
That's what I'm doing.
> That sounds interesting. Is there another thread where you've gone
> into detail about this?
No, not yet. I'm still experimenting with the design; I would like to
know a little better myself what I want to do before I start
discussing it :-)
> >> 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?
For 'd' and 'x' I would expect to see the equivalent of an "unsigned
long" as underlying data type; for 'p' we should probably use a
"physaddr_t" which might be > 32 bit even on 32 bit systems.
> > 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.
You mean the setenv() called from the DHCP code would behave
differently than the setenv() called from the command line? Now that
_is_ confusing to me. I doubt many users will understand what's going
on on such a system.
> > 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.
Not if it can be avoided easily. OTOH my new code will have commands
like "env default" or "env import" which will not care at all about
these variables, but simply do what you asked for. Dunno if this will
need to be changed - but if so, then I'd rather to this in the context
of a new read-only concept.
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: w...@denx.de
As far as we know, our computer has never had an undetected error.
-- Weisert
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
