[U-Boot-Users] simplify bootm command
Jerry Van Baren
gvb.uboot at gmail.com
Tue Aug 5 12:38:37 CEST 2008
Wolfgang Denk wrote:
> In message <48982523.4030706 at 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
More information about the U-Boot
mailing list