Hi On Wed, Jul 7, 2021 at 4:48 PM Marek Behun <marek.be...@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 -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __________________________________ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com