Re: [RFC PATCH 02/28] cli: Add LIL shell

Marek Behun
2021-07-07T14:48:09Z

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?

- 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