[snip]
As I look at this more and more I think trying to re-encode the control flow of the bootm command in a script is just insane. There are too many special cases we have to deal with that we'd just being moving from C code into the script.
My assumption is that a given board/config/user will likely be using exactly one of the n!/k!(n-k)! possibilities implemented in the current "bootm" (I don't know what n and k are, but n is pretty large and k is hard to determine :-O). I figure, in the worst case, a given user may want two or three possibilities.
that might be true in a custom board port but for reference boards like we produce at FSL its difficult to know what a customer might want so we effective have the kitchen sink.
By selecting from a (smallish) set of "simple" bootX scripts, I'm speculating that each script will not need conditional logic other than "&&" to bail out if an error occurs. I'm also suspicious that replacing "bootm" with a simplified "bootm" with a (single) "bootm" script isn't going to be workable (as you contend - script complexity)... the solution I would propose if that happens is to maintain "bootm" as is as a backwards compatible CONFIG_ option and create a new "bootsimple" (or some such) command that is what bootm would have been if we had hush scripting (and prescience[1]) a few years ago.
which means I'll have to keep the old method around.
Unless there is some believed simplification I'm missing I don't think going through all this effort produces anything that is significantly better.
To make an omelet, you have to break some eggs. :-) I see Wolfgang illustrated the current complexity with a list of bootm hack^H^H^H^H customizations in a separate message.
but I doubt we will be able to remove those as they should be dealing with the ARCH specific boot methods.
My needs are meet with the simple ft_env_setup() call out. Beyond that trying to rework bootm for legacy images, CONFIG_FIT, booting w/dts, boot w/o dts, linux, *bsd, vxworks, etc just seems like a lot of work w/o any real benefit.
That is the practical approach for now, but that is also how we got to here - incrementally adding complexity to bootm.
Fair point but I have yet to see how the new approach is going to get rid of the old one. What's the point in adding code if we can't get rid of the old code?
- k