On Mon, 26 Sep 2011 16:11:14 -0500 Scott Wood scottwood@freescale.com wrote:
On 09/26/2011 01:09 PM, Wolfgang Denk wrote:
In message 20110926112756.bb93d41b.kim.phillips@freescale.com you wrote:
We need to enable reverting an env var to its original default definition.
Do we? We have not had that feature for over a decade and nobody ever really suffered from it. Now we have "env -f reset" for almost a
I have suffered. I eventually found a trick - to omit the $othbootargs reference in nfsboot, which would eventually come back to haunt me when I really did want to use $othbootargs.
year, and guess how many percent of the users even know about this command? And how many have ever actually used it yet?
That's because the author didn't include feature self-advertisement code to setenv that detects whether a user starts setting too many variables to values that match their original default, and goes "<sigh> You know you could have just done an 'env -f reset', right?" ;)
But that doesn't necessarily help either - we may want to keep some of the other (modified) env vars, such as hw_config.
I think he's saying that one shouldn't be prohibited by length from manually typing "setenv nfsboot ..." to set a value that is no longer than (or even is identical to) the default value.
right.
Perhaps over time the nfsboot norm setting should be migrated to something more modular in the board config files, but right now, users are complaining about simply expecting to being able to type two more characters on the command line.
Then educate your users that a boot loader is a resource restricted environment, and that there at least 10 different ways to do what they want, at least 8 of them resulting in a much simpler and easier to comprehend environment setup.
What is the resource constraint here that prevents accepting longer console commands? This is a change to the config for a board that comes with multiple gigabytes of RAM. This is not code that runs prior to relocation.
Whether the environment scripts could, in time, be structured better is a separate issue from whether there's a good reason to keep this arbitrary limit at its current value that prevents people from manually typing in what is currently being used.
right, this is a flat-out user convenience patch - it saves development time in the short term. The long term goal of reprogramming hundreds of users in u-boot environment variable theory is not the purpose here.
Kim