From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DF14C07E99 for ; Mon, 5 Jul 2021 17:50:50 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6877D61970 for ; Mon, 5 Jul 2021 17:50:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6877D61970 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DF8E582BFA; Mon, 5 Jul 2021 19:50:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1625507447; bh=OusUfUGI5RiN15foE6Mu9kYK770v2rI4P3g41ErYOJc=; h=To:cc:From:Subject:In-reply-to:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=eKA92Sx1OPoysuqfEH5Z6YjfKU81Me+vV+Bm5UzkezP9mb27GEnab7p3s0H4/+0rY h8/JBFZYu31X+i0cNp88hZDjC3tzl30aRANYDoAa4zo1NVaoM59w6v0XMaoTni9r0O qb0y9rfeJp7fIIgyzHveFe1n0r6SW2BQXvrXWhZLS1DMF4R10jlao6H5Gt2+Om6ahi VHk+N50ngSlIZFSSn49C1WJcCPZ+gB4OSy3aABLW3GFb3JtwclIrSOvojREoMHq3I5 MiCrt0wtzk6TPhXXb8ONZf+7K4Fm8rEX318n5kfy62F/9WTZUkRikpE2BxSi5SomHs 2seOTsxE61b8Q== Received: from janitor.denx.de (unknown [62.91.23.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: noc@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 1BFAB82BD7 for ; Mon, 5 Jul 2021 19:50:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1625507444; bh=OusUfUGI5RiN15foE6Mu9kYK770v2rI4P3g41ErYOJc=; h=To:cc:From:Subject:In-reply-to:References:Date:From; b=pJjCyMwCPYGlz97vknKttIzo5kP6cD00aCIHLgHCXYRpeiSt+ON2OWc7I1UlMQL7m Y/dDG1QipmxHtqkZyb2iCwyzttbnsOLMqMVXMWPsnill6oItv4D6QyA/DKzbJugy3H CWG4lGJDDY/P7JMCKweD4X3QDPuxz8764kgioLNVk8E8e+Qk9VCVu6Y5T8KEY/2YWW BgTfb6Bi98gr8gRCcfnC01w/1i9eLDy2PYoRhv2p6FjDnPHubrVwkaOWhrAbEspAkJ 1Nep02xAWp5b66uZDG9lfvzWsqBL5rRdrD+9Yd8k2AkfCJjxNKZBceAs4T5L7fSCVS 3WHz2Q/UyXXIA== Received: by janitor.denx.de (Postfix, from userid 108) id B37FAA0228; Mon, 5 Jul 2021 19:50:43 +0200 (CEST) Received: from gemini.denx.de (gemini.denx.de [10.4.0.2]) by janitor.denx.de (Postfix) with ESMTPS id 9D9E3A003B; Mon, 5 Jul 2021 19:50:34 +0200 (CEST) Received: from gemini.denx.de (localhost [IPv6:::1]) by gemini.denx.de (Postfix) with ESMTP id 3A8B31E1498; Mon, 5 Jul 2021 19:50:34 +0200 (CEST) X-Mailer: exmh version 2.9.1 11/07/2018 with nmh-1.7.1 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: U-Boot To: Sean Anderson cc: Steve Bennett , Rasmus Villemoes , u-boot@lists.denx.de, Tom Rini , =?UTF-8?Q?Marek_Beh=c3=ban?= , Simon Glass , Roland Gaudig , Heinrich Schuchardt , Kostas Michalopoulos From: Wolfgang Denk Subject: Re: [RFC PATCH 03/28] cli: lil: Replace strclone with strdup MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8bit In-reply-to: <5a967151-94f0-6037-2d02-0114c43b846c@gmail.com> References: <20210701061611.957918-1-seanga2@gmail.com> <20210701061611.957918-4-seanga2@gmail.com> <17176.1625340369@gemini.denx.de> <54A6EFA6-8D5B-4779-B344-87BCC8C14B9C@workware.net.au> <5a967151-94f0-6037-2d02-0114c43b846c@gmail.com> Comments: In-reply-to Sean Anderson message dated "Mon, 05 Jul 2021 10:42:02 -0400." Date: Mon, 05 Jul 2021 19:50:34 +0200 Message-ID: <163090.1625507434@gemini.denx.de> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Dear Sean, In message <5a967151-94f0-6037-2d02-0114c43b846c@gmail.com> you wrote: > > AIUI hush has diverged significantly from what U-Boot has. This would > not be an "update" moreso than a complete port in the style of the > current series. Agreed. However, as you write this it sounds like a big problem only. I disagree here - it is also a chance to do a few things different than with the original port. Please keep in mind when this original port of the hush shell was done: it was a time when many systems came with a total of 4 MB flash memory, and not only U-Boot, but also the Linux kernel and a ram-disk image or such had to fit into that. At that time 40 or 60 kB code size for just a fancy shell was immense! Under such restrictions (and the need to complete the task with a given budget) many things were just commented out which from today's point of view would be nice to have. This is not a problem of the code complexity or resources, but only of different requirements and different resources. > I don't think sh-style shells are a good match for U-Boot's execution > environment in the first place. The fundamental idea of an sh-style > shell is that the output of one command can be redirected to the input > (or arguments) of another command. This cannot be done (or rather would > be difficult to do) in U-Boot for a few reasons There is an old saying: The loser says: "It might be possible, but it is too difficult." The winner says: "It might be difficult, but it is possible." Apparently you take another position here than me. First, I disagree that pipes are the "fundamental idea" of a shell. It is a fundamental idea of the UNIX operating systems, indeed. But please keep in mind that we are here in a boot loader, not in a full-blown OS context. > * U-Boot does not support multithreading. Existing shells tend to depend > strongly on this feature of the enviromnent. Many of the changes to > U-Boot's hush are solely to deal with the lack of this feature. I disagree to both parts of your statement. Multithreading (or rather, a concept of separate processes which can eventually even run in parallel) is very nice to have, but it is not mandatory in most cases. Command pipes can almost always be strictly sequentialized and thus run in a single-task environment, too. I'm not sure, but I think I even remember pipes in the "shell" of the CPM "OS" on Z80 processors a number of decades ago... And the fact that our current version of hush did not attempt to keep these features was much more driven by strict memory footprint limitations that anything else. I claim it would have been possible, and still is. You also don't mention (and I guess you oversee) another critical fact: so far, U-Boot has no concept of files. The classic design principle "everything is a file" is missing even more than the concept of processes. > * Existing commands do not read from stdin, nor do they print useful > information to stdout. Command output is designed for human > consumption and is substantially more verbose than typical unix > commands. This is a statement which is correct, but it does not contain any pro or con for the discussion here. And if we had the features, it would be easy to fix. > * Tools such as grep, cut, tr, sed, sort, uniq, etc. which are extremely > useful when working with streams are not present in U-Boot. You are talking about OS environments here. But we are a boot loader. Also, this argument is not fair, as the suggested LIL does not provide grep, sed, awk, sort, uniq etc. functionality either, or does it? > And of course, this feature is currently not present in U-Boot. To get Correct, and for very good reasons. > which will set my_uuid to the uuid of the selected partition. My issue > with this is threefold: every command must add new syntax to do this, > that syntax is inconsistent, and it prevents easy composition. Consider > a script which wants to iterate over partitions. Instead of doing > > for p in $(part list mmc 0); do > # ... > done > > it must instead do > > part list mmc 0 partitions > for p in $partitions; do > # ... > done > > which unnecessarily adds an extra step. This overhead accumulates with > each command which adds something like this. Apparently you fail to understand that this "extra step" is primarily due to the fact that we are single tasking. Even if we has command substitution (like we could have with hush) the execution sequence would be serialized in exactly the same way under the hood - it's just not as directly visible. > Both of these workarounds are natural consequences of using a sh-tyle > shell in an environment it is not suited for. If we are going to go to No, they are not. They are much more the consequence of no strict design guidelines for commands, so everybody implements what fits his purposes best. A cleaner approach does not require any of the additional features you've asked for - it would be possible as is. > the effort of porting a new language (which must be done no matter if > we use Hush or some other language), we should pick one which has better > support for single-threaded programming. In which way do you think "a new language" needs to be ported when switching from an old to a new version of hush? It would be still a (mostly) POSIX compatible shell, with some restrictions. I can fully understand that you defend your proposal, but let's be fair and stick with the facts. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de To get something done, a committee should consist of no more than three men, two of them absent.