On 7/5/21 1:58 PM, Wolfgang Denk wrote:
Dear Sean,
In message <d808990b-623d-d962-c7d6-e40063bc5...@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...
I don't particularly mind if Kostas doesn't view these patches as good
additions to upstream. We have different goals and requirements, and so
not all changes will be compatible.
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,
The bugs are fairly minor. The particular characteristics of Hush have
not changed. These characteristics make Hush difficult to adapt to the
limitations of U-Boot. When we cannot support the basic abstractions
expected by Hush, the shell will necessarily change for the worse.
but cannot be easily fixed in U-Boot
Because they are core to the design of Hush (and other bourne derived
shells).
because we essentially created an unmaintained fork
I plan to maintain this fork.
--Sean
- 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.
Best regards,
Wolfgang Denk
