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
signature.asc
Description: PGP signature
