[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Pantelis Antoniou]

Wolfgang Denk wrote:

>In message <408CF369.9050907 at intracom.gr> you wrote:
>
>>>Well, but how do you present it to the user? Will "printenv" show all
>>>variables mixed? So how does the user know which get saved and  which
>>>not?  How  do  you  merge  both  with  the standard CLI and hush in a
>>>consistent way? And allthis without  (significantly)  increasing  the
>>>memory footprint _and_ keeping the code readable?
>>>
>>>
>>>
>>Well, will the user care?
>>
>
>I hope you are joking here. Of course he will.
>
>
We have a different definition of a "user" in mind it seems.
Your users appear to be much more technical inclined than mine...

>>Why should he know that the version or the clock variable is real?
>>
>
>He  must  know  which  variables  are  available  when  reading   the
>environment  under Linux. He must know which variables can be changed
>(with the changes showing some effect). Etc. etc.
>
>
>>If he tries to change a read only variable it should be denied.
>>
>
>Per definitionem there should be no variables in the environment that
>cannot be changed. Period.
>
>I know that there is the big exception of "ver" (I had a weak  moment
>when  I  alloed  for  that),  and there are the smaller exceptions of
>serial# end ethaddr which are settable  only  once  (usually  by  the
>vendor), but this is at least configurable.
>
>
Ideological purity is a worthy endeavor.
The real world has different things in mind.

>>Since the variables are present at RAM but not in persistent storage
>>the size of the environment is the same. As for the code footprint
>>this is debatable. If someone needs this "feature" he can enable
>>it explicitly. If not enabled everything should work as it were.
>>
>
>I think the concept of environment variables as we  have  so  far  is
>conceptually  pretty  clean.  What you suggest is different, and does
>not fit. That does NOT mean that your idea is bad - not at  all.  BUt
>such  "automatic"  variables must be kept separated from the environ-
>ment. They shall not be  mixed  in  the  display  of  the  "printenv"
>command, and not be settable by "setenv".
>
>Please feel free to implement new "printvar" and "setvar" commands as
>optional extension, but I really don't see that much benefit. Already
>now it is pretty ifficult to find a variable definition  in  a  long,
>multi-page "printenv" output.
>
>
>
Hmm, do I see a grep in the future? ;).

>Best regards,
>
>Wolfgang Denk
>
>
Anyway, this discussion is pretty academic at the moment.
We'll cross this bridge when we get there.

Regards

Pantelis