Re: [RFC PATCH 05/28] cli: lil: Rename some functions to be more like TCL

[Tom Rini <trini@konsulko.com>]

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

On Wed, Jul 07, 2021 at 10:16:13AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20210706153327.GS9516@bill-the-cat> you wrote:
> > 
> > > Mature?  And still without consequent error checking?  And done,
> > > i.  e. this will never be fixed?
> >
> > Intentional design by upstream, and then for the actual problem part
> > (error checking, test suite), Sean is saying he'll fix it, and has
> > started on it.
> 
> Seriously - any piece of software that omits error checking
> intentionally be design should be indented six feet downward and
> covered with dirt.  We should not even consider looking at it.
> 
> > OK, snark aside, I'm very serious here, any "we'll just import ..."
> > needs to have a plan to keep it up to date, or be easy enough to do such
> > that I can set a monthly reminder to check for and do the update.  Every
> > area where we don't do this is a set of problems waiting to get worse,
> > as we can see with the hush shell right now as it's one of the oldest
> > things we stopped syncing with.
> 
> Which exact _new_ problems do we see with hush right now?  I can
> only see old ones, that have been known (and worked around) for
> nearly two decades.
> 
> The limitations and bugs have all been there since the beginning -
> the limitations actually being intentional due to the typical
> resource situation at that time.

There's all of the new features that've been suggested for our current
hush, many by Sean, for which the reply has been "our hush is old, it
should be updated!".

And you didn't address my point, taking code from another project
requires dedicated maintenance to keep it up to date and we do have a
lot of in-tree examples right now of where that lack of dedicated
maintenance is a problem.

> > But I
> > really think we want a shell environment that is not actively adding new
> > features is a good thing, for the default.  Just how much stuff should
> > we be doing or need to be doing before we hand things over to the OS?
> 
> You are shooting yourself in the knee here.
> 
> If you think out CLI should not be adding new features, then we
> should just stick with our ancient hush and neither update it nor
> replace it with something else that adds not only new features, but
> breaks backward compatibility, hard.

Honestly, adding new features to the CLI (which is NOT the same as
adding new commands, or enhancing existing commands) is very low on my
priority list.  We need to get the Kconfig migration done.  We need to
get DM migration done (which will help with the Kconfig one by showing
hardware no one cares for anymore, and reducing symbols).  We need to
make adding new hardware easier.  We need to get DTS files in-sync more
often.

There are very important developer use cases for a more flexible CLI
interpreter.  But the main use case is still "boot the (redundant) OS
ASAP".

So, what is my priority on this series right here?  Well, a developer
has posted a series.  They believe it's useful and addressing a
long-standing problem.  They want feedback.  I'm trying to provide
feedback as it's to a general area of the codebase.

-- 
Tom

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