From: Wolfgang Denk <wd@denx.de>
To: Tom Rini <trini@konsulko.com>
Cc: "Simon Glass" <sjg@chromium.org>,
"U-Boot Mailing List" <u-boot@lists.denx.de>,
"Marek Behún" <marek.behun@nic.cz>,
"Rasmus Villemoes" <rasmus.villemoes@prevas.dk>,
"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
"Joe Hershberger" <joe.hershberger@ni.com>
Subject: Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
Date: Thu, 21 Oct 2021 15:06:51 +0200 [thread overview]
Message-ID: <3695947.1634821611@gemini.denx.de> (raw)
In-Reply-To: <20211021122325.GX7964@bill-the-cat>
Dear Tom,
In message <20211021122325.GX7964@bill-the-cat> you wrote:
>
> Do you have any other feedback on the entire rest of the series?
I already wrote that I support the concept, and the few nit I saw
have been fixed, I think. Except this unneeded breaking of backward
compatibility.
> Because I'm not sure the benefit of "we can still support '+' at the end
> of a variable name, if anyone uses that" outweighs "we can more easily
> append variables in constructing our environment without relying on
> uncommon operators".
We introduce a new feature here. Defining an append operator is a
convenience thing. It could probably also solved using the
preprocessor, likely in a more ugly way.
In any case, the feature is new, and the operator is new.
For the implementation it does not matter if we define this operator
as "+=" or '=+" or "=." or something else.
the only difference is that any ioperator starting with an equal
sign is inherently backward compatible without need for arbitrary
new restrictions.
> To me "=+" as the append syntax is worse than "no
> + at the end of your variables".
In which way is it worse? For esthetic reasons?
I confirm that '+=' looks better. But '+=" is technically broken.
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
Brain: an apparatus with which we think we think. - Ambrose Bierce
next prev parent reply other threads:[~2021-10-21 13:07 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
2021-10-19 22:44 ` [PATCH v9 1/7] sandbox: Drop distro_boot Simon Glass
2021-10-19 22:44 ` [PATCH v9 2/7] doc: Move environment documentation to rST Simon Glass
2021-10-20 6:38 ` Heinrich Schuchardt
2021-10-22 3:05 ` Simon Glass
2021-10-19 22:44 ` [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file Simon Glass
2021-10-21 9:50 ` Wolfgang Denk
2021-10-21 12:23 ` Tom Rini
2021-10-21 13:06 ` Wolfgang Denk [this message]
2021-10-21 13:25 ` Marek Behún
2021-10-21 13:28 ` Marek Behún
2021-10-21 15:12 ` Wolfgang Denk
2021-10-21 15:18 ` Tom Rini
2021-10-21 15:59 ` Simon Glass
2021-10-21 16:03 ` Tom Rini
2021-10-21 16:51 ` Simon Glass
2021-10-22 6:40 ` Rasmus Villemoes
2021-10-24 19:54 ` Simon Glass
2021-10-25 7:06 ` Rasmus Villemoes
2021-10-25 15:18 ` Simon Glass
2021-10-25 19:52 ` Rasmus Villemoes
2021-10-26 10:15 ` Wolfgang Denk
2021-10-28 14:18 ` Simon Glass
2021-10-22 8:08 ` Wolfgang Denk
2021-10-22 14:47 ` Tom Rini
2021-10-24 15:46 ` Wolfgang Denk
2021-10-24 16:44 ` Tom Rini
2021-10-25 7:48 ` Wolfgang Denk
2021-10-22 8:06 ` Wolfgang Denk
2021-10-22 14:04 ` Marek Behún
2021-10-22 14:50 ` Tom Rini
2021-10-19 22:44 ` [PATCH v9 4/7] sandbox: Use a text-based environment Simon Glass
2021-10-20 6:58 ` Alexander Dahl
2021-10-19 22:44 ` [PATCH v9 5/7] doc: Mention CONFIG_DEFAULT_ENV_FILE Simon Glass
2021-10-19 22:44 ` [PATCH v9 6/7] doc: Improve environment documentation Simon Glass
2021-10-19 22:44 ` [PATCH v9 7/7] bootm: Tidy up use of autostart env var Simon Glass
2021-10-21 14:02 ` [PATCH v9 0/7] env: Allow environment in text files Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3695947.1634821611@gemini.denx.de \
--to=wd@denx.de \
--cc=joe.hershberger@ni.com \
--cc=marek.behun@nic.cz \
--cc=rasmus.villemoes@prevas.dk \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox