[U-Boot-Users] simplify bootm command

[Jerry Van Baren <gvb.uboot@gmail.com>]

Wolfgang Denk wrote:
> In message <48982523.4030706@gmail.com> you wrote:
>> My current best thought is to create a new "boot simple" (boots? 
>> bootsm?) command that contains only the essence of bootm.  I would then 
>> change the command "bootm" to do a hush script run of the env variable 
>> "bootm" (i.e. the command "bootm" would really just be "run bootm"). 
>> The env variable "bootm" would then have to be created with the complex 
>> (board/config appropriate) sequence that is currently hardcoded in the 
>> command "bootm", with the last command being "boots", of course.  This 
>> would be selected by a new CONFIG_ configuration so that old boards 
>> would go on as is until or unless the maintainer chose to move forward.
> 
> Hm... if we go to such efforts, we might even go one step farther and
> solve the problem in a more general way.
> 
> One idea that has been spinning in my mind for some time is  to  make
> the  "run"  command to execute the content of an environment variable
> optional. Instead, we could try and handle environment variable names
> similar to command names, i. e. instead of typing "run foo; run  bar"
> you  could  just  write  "foo;  bar" (I woull probably still keep the
> "run" command around to allow for the implicit error handling as used
> in "run foo bar" without forcing the user to use the  hush  shell  to
> get the equivalent "foo && bar").
> 
> Then it's just a matter of defining the search order: if the variable
> name space gets searched before the command names, we could  redefine
> all builtin commands. [Probbaly the search order (variables before or
> after   builtin  commands)  can  be  even  mad  selectable  using  an
> environment variable :-) ].
> 
> A new "builtin" command would allow to stillr efer to the original
> builtin commands.
> 
> With such an implementation, we could move the FDT  handling  into  a
> command  sequence  stored  in a "bootm" environment variable, and the
> last part of this variable would be "builtin bootm" to run  the  real
> (simplified) command.
> 
> What do you think?

That would be REALLY cool!  It would take some initial work, but the 
reward would be really simple and transparent expandability for the 
command set.  As with the "bootm" command, we might end up with simpler 
code (I don't think too many commands are as bad as bootm, however).

One minor flaw, I don't see how "bootm" the env script could run "bootm" 
the built-in command, because it would instead recursively run "bootm" 
the env script if scripts have higher priority and the command line 
"bootm" would run the built-in "bootm" if scripts have lower priority. 
The way I see it, env scripts should have higher priority than built-in 
commands and would supercede the built-in.  Hmm, one possible way out of 
the dilemma would be to support quoting built-in commands to force them, 
rather than the env script: `bootm` would be the built-in command (just 
as a concept, I don't know how back-tick quoting would conflict with 
existing hush parsing).

gvb