On Mon, 26 Sep 2011 16:11:14 -0500 Scott Wood <scottw...@freescale.com> wrote:
> On 09/26/2011 01:09 PM, Wolfgang Denk wrote: > > In message <20110926112756.bb93d41b.kim.phill...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
