Hi
On Wed, Jul 7, 2021 at 4:48 PM Marek Behun marek.behun@nic.cz wrote:
Dear Tom, Sean, Wolfgang and others,
here are some of my opinions for this discussion
I agree with Wolfgang that there are far better options than a Tcl-like shell, if we want to add another language
I also think that instead of adding another language, it is more preferable to improve the existing one. Adding a new language will cause more problems in the future:
- I think it can end up with OS distributions needing to write boot scripts in both languages, because they can't be sure which will be compiled into U-Boot
- we will certainly end up with more bugs
- userbase will fragment between the two languages
I think we can start improving the current U-Boot's shell in ways that are incompatible with upstream Hush.
The idea back then, as I understand it, was to minimize man-hours invested into the CLI code, and so an existing shell was incorporated (with many #ifdef guards). But U-Boot has since evolved so much that it is very probable it would be more economic to simply fork from upsteam Hush, remove all the #ifdefs and start developing features we want in U-Boot. Is upstream Hush even maintained properly? What is the upstream repository? Is it https://github.com/sheumann/hush?
I think that hush is the one that is now in the busybox. I could spent ten minutes this morning and this is my short list:
- we have several define that allow it to enabled e/o disable a lot of features - we are talking about 11K lines compared to 3K (including comment) - we have 25-30 configuration option on hush on busybox - in u-boot code some of the problem was solved some time ago - as describe is 68Kb, I think this consider all the option enables - the code is different from what we have and what is there
I don't know if options like ENABLE_HUSH_JOB and ENABLE_MMU can partially solve some of the problems described in the thread
* Sean *: You have spent more on this, can you please complete it.
Out of that. Do we have some script shell unit test in uboot?
Michael
even if we decide to stay with upstream Hush and just upgrade U-Boot's Hush to upstream (since it supports functions, arithmetic with $((...)), command substitution with $(...), these are all nice features), it is IMO still better than adding a new language
one of the points Sean mentioned with LIL is that when compiled, it's size does not exceed the size of U-Boot's Hush.
If we were to add new features into U-Boot's Hush, the code size would certainly increase.
I think we should implement these new features, and instead of adding a new language, we should work on minimizing the code size / resulting U-Boot image size. This is where U-Boot will gain most not only with it's CLI, but also everywhere else. Regarding this,
- we already have LTO
- Simon worked on dtoc so that devicetrees can be compiled into C code
- we can start playing with compression
- either we can compress the whole image for machines with enough RAM but small place for U-Boot (Nokia N900 for example has only 256 KiB space for U-Boot)
- or we can try to invent a way to decompress code when it is needed, for machines with small RAM
Marek