From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pantelis Antoniou Date: Mon, 26 Apr 2004 16:25:26 +0300 Subject: [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ In-Reply-To: <20040426130328.B9BE4C109F@atlas.denx.de> References: <20040426130328.B9BE4C109F@atlas.denx.de> Message-ID: <408D0DC6.1050602@intracom.gr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: >In message <408CF369.9050907@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