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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]

On Wed, Jul 07, 2021 at 09:46:20AM -0400, Sean Anderson wrote:
> 
> On 7/7/21 4:15 AM, Wolfgang Denk wrote:
> > Dear Tom,
> > 
> > In message <20210706154346.GT9516@bill-the-cat> you wrote:
> > > 
> > > I'm pretty confident that exactly zero people have written complex
> > > U-Boot scripts and then been happy about the experience.
> > 
> > I have seen many U-Boot scripts which were pretty complex, but
> > working absolutely reliably.
> > 
> > > TCL has its fans.  csh has it's fans.  The question isn't what's the
> > > best desktop shell or general scripting language, but what's the most
> > > useful in our environment an use cases.
> > 
> > Maybe you should try and do a poll of our user base which CLI they
> > _want_?  I doubt there will be any significant percentage voting for
> > Tcl.
> > 
> > I know of a large number of systems which offer a shell interface on
> > their command line, and those who don't usually use completely
> > proprietary code.  I know of very few examples where Tcl is being
> > used.
> 
> Off the top of my head, most of the tooling for FPGAs uses TCL for
> scripting. OpenOCD uses it too.
> 
> > > I don't know if it's right either.  But drawing on my comment just now
> > > and above about complex boot scripts, I also don't know if "it's sh but
> > > quirky and incomplete, WHY DOESN'T THIS WORK RIGHT" is better than "It's
> > > TCL?  I don't know that, let me hit stackoverflow and do a little
> > > reading" as would be the common experience.  Especially if we document
> > > up-front what the quirks we have are.
> > 
> > 
> > Point taken.  But if you think this to an end, the result is: lets
> > write some documentation and explain the limitations of a shell in
> > U-Boot environment, and document the warts and bugs of this (or an
> > updated) version of hush.  This should make more users happy than
> > completely new and incompatible stuff.
> > 
> > 
> > Frankly, I believe when you run into problems with hush in U-Boot
> > (even the current version) you should lean back and think about what
> > you are doing.
> > 
> > U-Boot is a boot loader, and while it is powerful enough to do
> > complex things, this is not necessarily the most clever approach.
> > 15 years ago, I've written complex update scripts for U-Boot. This
> > was easy enough to do, and worked perfectly.  But there are so many
> > limitations in a boot loader environment.  We don't do this any
> > more.  Instead, we use an OS suitable for such tasks (Linux with
> > SWUpdate).
> > 
> > 
> > And talking about problems and limitations in U-Boot... Is the CLI
> > really our biggest concern right now?  None of our users (customers)
> > has asked for a better command interpreter - the question we hear
> > are more like: "When will you support IPv6?", "NFS does not work
> > with recent Linux distros, will this be fixed?", "Can I download
> > over WiFi?", "Can I download using HTTP/HTTPS?", "How can I harden
> > U-Boot for security-critical environments?", etc.
> 
> I wanted a better shell, so I worked on it.

This here is also an important point, and why I'm commenting on the
series.  A developer sees a problem, and works on the problem.  I know I
don't comment on as much stuff as I should, but for wide reaching
patches, I really really try to.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]