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: 3084 bytes --]

On Tue, Jul 06, 2021 at 09:52:56AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20210705185141.GA9516@bill-the-cat> you wrote:
> > 
> > I think I want to try and address this.  While with "hush" we have
> > something that's in heavy active development outside of U-Boot, with LIL
> > we have something that's mature and "done".
> 
> 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.

> > Tracking an active outside development is HARD and requires
> > constant resync.
> 
> Based on that logic we should stop supporting Linux, and stop using
> DTs or file systems - all of these are under "active outside
> development".
> 
> This is a bogus argiment.

Alright, go and update our Kbuild integration to be in sync with current
Linux.  Or just v5.0.  I'd suggest picking up the metadata_csum support
patch but someone did say they'd try and update that (off-list) so that
ext4 filesystem made with default options in the last 5 years (not
exaggerating) work.  I'm not even going to talk about the various level
of out of sync our DTs files are but I do have some hope there will be
more re-syncs especially as it comes to more light that the DT U-Boot
uses can just be the DT the OS gets.  Then tell me it's easy to keep
this stuff in sync.  Because we certainly don't want to just
fork-and-forget again, right?  Because that's why we have both crazy
parse bugs as well as lack of now old-and-expected features.

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.

> > Look at the last few
> > LIL releases.  That could be easily re-worked in to our fork if needed.
> > I see that as a positive, not a negative.
> 
> OK, this is your opinion.  Mine differs.
> 
> Please consider this as a full NAK from me when when you think of it
> as a _replacement_ (even an optional one) of the standard shell. If
> you like, have it added as an _additional_ command, of course fully
> optional and without impact on the rest of U-Boot if not
> intentionally selected.

Any new cli for U-Boot won't be a default build as a command for a long
while after it's merged.  I'm not sure how much past that point it would
further need to be to become the default cli.  And I'll even repeat what
I said elsewhere about how an sh syntax is a good user feature.  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?

-- 
Tom

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