All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Wolfgang Denk <wd@denx.de>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	 Tom Rini <trini@konsulko.com>,
	Joe Hershberger <joe.hershberger@ni.com>
Subject: Re: [PATCH v6 4/7] env: Allow U-Boot scripts to be placed in a .env file
Date: Mon, 18 Oct 2021 12:12:21 -0600	[thread overview]
Message-ID: <CAPnjgZ15KavTBZoML7dv_EaRJMyJvbA=kmY3Bgz4AeygwEppuQ@mail.gmail.com> (raw)
In-Reply-To: <3496103.1634558337@gemini.denx.de>

Hi Wolfgang,

On Mon, 18 Oct 2021 at 05:59, Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Simon,
>
> In message <CAPnjgZ106dBqzJdVYpufp4mztf3_eFoX9isSm=W_c5uDoFJVGA@mail.gmail.com> you wrote:
> >
> > > I really think your fixed filename proposal does not work well in
> > > reality.  The file name should be Kconfig configurable. See [1]
> > > for details.
> > >
> > > [1] https://lists.denx.de/pipermail/u-boot/2021-October/462668.html
> >
> > Yes I saw that but I forgot to look at it. I think it makes sense - we
> > do that with devicetree, for example.
> >
> > Is that the only thing holding you back?
>
> Basically yes - the only other concerns I have is about this +=
> construct which makes the '+' character an illegal character for
> environment variable names, but only when used at the end of the
> variable.  This is anything but nice or consistent. Iwonder what
> happens with notations like these:
>
>         foo+=bar        -> "bar" gets appended to current value of "foo"
> But what for:
>         foo\+=bar
> or
>         foo+ = bar
>
> ?

Can we just ban + ?

In the above, foo\+ gives an unknown escape sequence from the C
preprocessor, then the whole line is ignored by the script

foo+ = bar   produes a variable called "foo+ " in the environment with
the value " bar" so you probably don't want that.

>
> And please see also my comments about changing the autostart
> functionality for the user.

Yes I saw that and I think it is OK to change it. What do you think?

>
> > I haven't seen any positive comments to this series yet...
>
> Maybe many long-term users of U-Boot don't see the current situation
> as such a big problem?  I have no idea.

My original motivation was the complexity of getting the env you want
using #define

My current motivation is to complete the CONFIG migration, now in its 8th year.

Regards,
Simon

  parent reply	other threads:[~2021-10-18 18:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 18:22 [PATCH v6 0/7] env: Allow environment in text files Simon Glass
2021-10-14 18:22 ` [PATCH v6 1/7] binman: Allow timeout to occur in the image or its section Simon Glass
2021-10-14 18:22 ` [PATCH v6 2/7] sandbox: Drop distro_boot Simon Glass
2021-10-14 18:22 ` [PATCH v6 3/7] doc: Move environment documentation to rST Simon Glass
2021-10-14 18:22 ` [PATCH v6 4/7] env: Allow U-Boot scripts to be placed in a .env file Simon Glass
2021-10-15 14:32   ` Wolfgang Denk
2021-10-15 15:15     ` Simon Glass
2021-10-18 11:58       ` Wolfgang Denk
2021-10-18 13:37         ` Tom Rini
2021-10-18 14:10           ` Wolfgang Denk
2021-10-18 14:24             ` Tom Rini
2021-10-19 10:33               ` Wolfgang Denk
2021-10-18 18:12             ` Simon Glass
2021-10-19 10:38               ` Wolfgang Denk
2021-10-18 18:12         ` Simon Glass [this message]
2021-10-19 10:46           ` Wolfgang Denk
2021-10-19 14:11             ` Simon Glass
2021-10-19 16:09               ` Wolfgang Denk
2021-10-19 16:14                 ` Simon Glass
2021-10-14 18:22 ` [PATCH v6 5/7] sandbox: Use a text-based environment Simon Glass
2021-10-14 18:22 ` [PATCH v6 6/7] doc: Improve environment documentation Simon Glass
2021-10-14 18:22 ` [PATCH v6 7/7] bootm: Tidy up use of autostart env var Simon Glass
2021-10-15 14:45   ` Wolfgang Denk
2021-10-24 19:53     ` Simon Glass

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='CAPnjgZ15KavTBZoML7dv_EaRJMyJvbA=kmY3Bgz4AeygwEppuQ@mail.gmail.com' \
    --to=sjg@chromium.org \
    --cc=joe.hershberger@ni.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=wd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.