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

[Marek Behun <marek.behun@nic.cz>]

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