From: Dragan Simic <dsimic@manjaro.org>
To: Michael Walle <mwalle@kernel.org>
Cc: Caleb Connolly <caleb.connolly@linaro.org>,
clamor95@gmail.com, sjg@chromium.org, sumit.garg@linaro.org,
trini@konsulko.com, u-boot@lists.denx.de
Subject: Re: [PATCH v2] boot: add support for button commands
Date: Thu, 18 Jan 2024 15:33:33 +0100 [thread overview]
Message-ID: <bf263fe8e2cb0bb841efed72372ba954@manjaro.org> (raw)
In-Reply-To: <15c65f2d0d66826cd1cf1c5a18ca7f26@kernel.org>
On 2024-01-18 08:59, Michael Walle wrote:
>> Using CONFIG_EXTRA_ENV_SETTINGS should be good enough to provide
>> the fallback defaults. However, the users can still mess the things
>> up,
>> but again, they can do that already in many places.
>
> I disagree. In my case that is a last resort recovery. And it should
> work in any case. Even if the user has messed up anything (except
> from erasing the bootloader in the SPI flash ;)).
Maybe the solution could be another compile-time option to "lock down"
the built-in defaults provided through CONFIG_EXTRA_ENV_SETTINGS? If
that new option is selected, changes to the environment would make no
changes to the built-in defaults, i.e. those parts of the environment
would actually be ignored.
>>> In summary, the registered (compiled-in) command should always take
>>> precedence. If one wants to supply a default command which can be
>>> changed later, that can go via the (compiled-in) default environment.
>>
>> Sorry, this is a bit confusing to me. Didn't you write above that
>> the users should be able to change the associated commands through
>> the environment variables?
>
> I had two kinds of button commands in mind: immutable ones and mutable
> ones. The first can be achieved with compiled-in commands, the second
> with a default environment and environment variables.
>
> Also, whether a command is a mutable one or not is the decision of
> the developer (or the one who's compiling/configuring u-boot),
> not the user.
I believe that the additional compile-time option, which I proposed
above, could be extended to specify which of the built-in default
button-command associations are immutable, and which are allowed to be
modified through the environment variables.
next prev parent reply other threads:[~2024-01-18 14:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 11:51 [PATCH v2] boot: add support for button commands Caleb Connolly
2024-01-10 18:08 ` Dragan Simic
2024-01-10 20:09 ` Caleb Connolly
2024-01-11 9:38 ` Michael Walle
2024-01-18 6:57 ` Dragan Simic
2024-01-18 7:59 ` Michael Walle
2024-01-18 14:33 ` Dragan Simic [this message]
2024-01-18 15:11 ` Michael Walle
2024-01-18 15:14 ` Dragan Simic
2024-02-13 22:32 ` 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=bf263fe8e2cb0bb841efed72372ba954@manjaro.org \
--to=dsimic@manjaro.org \
--cc=caleb.connolly@linaro.org \
--cc=clamor95@gmail.com \
--cc=mwalle@kernel.org \
--cc=sjg@chromium.org \
--cc=sumit.garg@linaro.org \
--cc=trini@konsulko.com \
--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 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.