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

[Tom Rini]

On Mon, Jul 05, 2021 at 03:02:24PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 5 Jul 2021 at 12:51, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Mon, Jul 05, 2021 at 07:58:18PM +0200, Wolfgang Denk wrote:
> > > Dear Sean,
> > >
> > > In message <d808990b-623d-d962-c7d6-e40063bc5dab at gmail.com> you wrote:
> > > >
> > > > > Is your intent to create a fork of this in U-Boot?
> > > >
> > > > Yes. I believe some of the major additions I have made (especially "[RFC
> > > > PATCH 21/28] cli: lil: Add a distinct parsing step") would not be
> > > > accepted by upstream.
> > >
> > > Ouch...
> > >
> > > > > Could we not update things upstream, at least as an option, to avoid
> > > > > carrying these patches?
> > > >
> > > > For some of the smaller patches, that may be possible. However, I am not
> > > > a fan of the major amount of ifdefs that Hush has. For something as core
> > > > as a shell, I think we should be free to make changes as we see fit
> > > > without worrying about how it will affect a hypothetical backport.
> > >
> > > I'm afraind I cannot understand your thinking.
> > >
> > > You complain that the existing port of hus has a number of severe
> > > limitations or bugs which have long been fixed upstream, but cannot
> > > be easily fixed in U-Boot because we essentially created an
> > > unmaintained fork - and as a cure, you recommend to do the same
> > > thing again, but this time intentionally and deliberately?
> > >
> > >
> > > If you had not apparently already invested a lot of effort into this
> > > thing I would assume you must be joking...
> > >
> > > To me such an approach is unacceptable.
> >
> > 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".  Tracking an active outside
> > development is HARD and requires constant resync.  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.
> 
> Yes I wondered about that, since hush has been in busybox, an active
> project, all these years. I think this is a good point and perhaps
> means that forking it should not be too much of a concern. Still, if
> we can send some things upstream, we should.

Well, that's part of the problem.  If we re-port modern hush, who is
going to keep it in sync, and how often?  Yes, there will be changes we
don't need, but there will be bugfixes we do as well.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210705/0b08493d/attachment.sig>