[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
panto at intracom.gr
Mon Apr 26 15:25:26 CEST 2004
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? ;).
Anyway, this discussion is pretty academic at the moment.
We'll cross this bridge when we get there.
More information about the U-Boot