[PATCH v2] boot: add support for button commands
Michael Walle
mwalle at kernel.org
Thu Jan 18 16:11:10 CET 2024
>>> 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.
Not sure locking down the whole environment is a good idea.
>>>> 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.
IIRC there is already a mechanism for that. Environment hooks
or something like that. But I'm not sure that has other implications
and qualify as simple and lightweight for this use-case.
Anyway, we digress. I just wanted to make you aware of another
use-case, which btw. is already done today in the lsxl board for
example.
-michael
More information about the U-Boot
mailing list