From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [PATCH 11/11] bootm: Support string substitution in bootargs
Date: Wed, 21 Oct 2020 09:16:06 +0200 [thread overview]
Message-ID: <329379.1603264566@gemini.denx.de> (raw)
In-Reply-To: <CAPnjgZ1SfwRa_LXh0zu3Oug=GLEUQx5MdCCvqW90-FV5hvX9uw@mail.gmail.com>
Dear Simon,
In message <CAPnjgZ1SfwRa_LXh0zu3Oug=GLEUQx5MdCCvqW90-FV5hvX9uw@mail.gmail.com> you wrote:
>
> > Yes, it takes one additional step, but it's simple and does not need
> > extra code.
>
> It is actually not simple, for three reasons:
>
> 1. With zboot the args come from the kernel setup.bin and must be modified
Don't use zboot, then. In my opinion, zboot is crap and should
never have been added, but there were so many requests for it.
Nevertheless, the use of crippleware is a sin that carries with it
its own punishment.
Don't do it, then.
Or, if you feel there is some value in zboot that should be
conserved, fix it to work like the rest of U-Boot.
> 2. With Chrome OS the args come from the kernel partition and must be
> augmented / substituted
OK. But then why can we not still use the standard variable
substitution mechanism we already have?
> 3. The above command cannot be in the same env var as anything else,
> since substitution breaks in that case
Sorry, I don't understand what you mean heare. What is "the same
env var" versus "anything else"? Maybe you can give a specific example?
> So you end up with a really complicated mess of environment variables
> and scripts that is barely manageable. I want it to be simple.
Again, I can't follow you. Why must there be a mess?
> See here for example (this only deals with 3 above, not 1 and 2, which
> would still need custom code without my series)
>
> https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/heads/chromeos-v2013.06/include/configs/chromeos.h#204
Sorry - all I see there is some complex settings if these make sense
I can't tell) - but how would things be better if you could - for
example - use "%U" instead of "${uuid}" as you suggested?
Also, is your approach not necessarily limited? You can now think of
a handful of variables you may want to pass, say root device, root
partition, uuid, maybe MAC address etc. But the next user will need
kernel args that you did not think of - so how do we proceed? Add
all features anybody needs to that new code? That certainly does
not scale. Or mix "%FOO" and "${foo}" style arguments? That's even
worse. I really fail to see the benefits, I see only ugliness and
problems.
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 at denx.de
Good manners are the settled medium of social, as specie is of
commercial, life; returns are equally expected for both.
- Lord Chesterfield _Letters to his Son_, 25 December 1753
next prev parent reply other threads:[~2020-10-21 7:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 13:55 [PATCH 00/11] bootm: Support substitions in bootargs and add tests Simon Glass
2020-10-19 13:55 ` [PATCH 01/11] env: Allow returning errors from hdelete_r() Simon Glass
2020-10-19 13:55 ` [PATCH 02/11] bootm: Add tests for fixup_silent_linux() Simon Glass
2020-10-19 13:55 ` [PATCH 03/11] bootm: Update fixup_silent_linux() to return an error Simon Glass
2020-10-19 13:55 ` [PATCH 04/11] bootm: Rename fixup_silent_linux() Simon Glass
2020-10-19 13:55 ` [PATCH 05/11] bootm: Add a bool parameter to bootm_process_cmdline_env() Simon Glass
2020-10-19 13:55 ` [PATCH 06/11] bootm: Use size rather than length for CONSOLE_ARG Simon Glass
2020-10-19 13:55 ` [PATCH 07/11] bootm: Split out bootargs environment reading / writing Simon Glass
2020-10-19 14:45 ` Wolfgang Denk
2020-10-20 19:12 ` Simon Glass
2020-10-21 7:02 ` Wolfgang Denk
2020-10-21 15:51 ` Simon Glass
2020-10-19 13:55 ` [PATCH 08/11] bootm: Update bootm_process_cmdline_env() to use flags Simon Glass
2020-10-19 13:56 ` [PATCH 09/11] bootm: Allow updating the bootargs in a buffer Simon Glass
2020-10-19 14:46 ` Wolfgang Denk
2020-10-20 19:12 ` Simon Glass
2020-10-21 6:57 ` Wolfgang Denk
2020-10-21 15:51 ` Simon Glass
2020-10-19 13:56 ` [PATCH 10/11] x86: zimage: Add silent-console processing Simon Glass
2020-10-19 13:56 ` [PATCH 11/11] bootm: Support string substitution in bootargs Simon Glass
2020-10-19 14:43 ` Rasmus Villemoes
2020-10-19 15:50 ` Simon Glass
2020-10-20 13:19 ` Wolfgang Denk
2020-10-19 14:54 ` Wolfgang Denk
2020-10-19 15:47 ` Michael Walle
2020-10-19 15:52 ` Simon Glass
2020-10-20 13:26 ` Wolfgang Denk
2020-10-20 19:23 ` Simon Glass
2020-10-21 7:16 ` Wolfgang Denk [this message]
2020-10-21 15:51 ` Simon Glass
2020-10-22 12:32 ` Wolfgang Denk
2020-11-03 15:11 ` Simon Glass
2020-10-19 15:50 ` Simon Glass
2020-10-20 13:17 ` Wolfgang Denk
2020-10-20 19:23 ` Simon Glass
2020-10-19 14:39 ` [PATCH 00/11] bootm: Support substitions in bootargs and add tests Heinrich Schuchardt
2020-10-20 19:12 ` 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=329379.1603264566@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.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