On 2020-01-20 11:59, Wolfgang Denk wrote:
Dear Joel,
In message <7cac871967a1317cea251e78d67a3...@lixil.net> you wrote:
>> +config USER_ENV_SETTINGS
>> + string "User build-time additional environment entries"
>> + help
>> + This value is reserved for the building user to provide custom
>> + environment entries to be added to the default environment. Care
>> must
>> + be taken to not break the environment, incompatible entries may
>> cause
>> + failure to compile, or failure of the target board to properly
>> + initialize or boot. The format is key=value pairs, with entries
>> + separated by C-style escaped null terminated values, such as:
>> + "key1=valueA\0key2=valueB\0key3=valueC".
>
> Something in your descripotion must be missing, or this change makes
> no sense to me.
>
>> #ifdef CONFIG_EXTRA_ENV_SETTINGS
>> CONFIG_EXTRA_ENV_SETTINGS
>> +#endif
>> +#ifdef CONFIG_USER_ENV_SETTINGS
>> + CONFIG_USER_ENV_SETTINGS
>> #endif
>
> What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS and
> CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with
> CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way
> with CONFIG_EXTRA_ENV_SETTINGS?
...
The main different to me is that many boards set/replace
CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time
configuration value. As a result, I can actually specify values for
CONFIG_USER_ENV_SETTINGS and have them included in the resulting
environment instead of overridden by the board configuration.
But what exactly is the difference between editing some include
file to change CONFIG_EXTRA_ENV_SETTINGS or editing some include
file to change CONFIG_USER_ENV_SETTINGS ?
To me this makes no sense.
The primary difference is in how we store the changes - include file
changes are necessarily in-tree source changes, whereas setting the
Kconfig value can be easily done by script obtaining the needed values
from an external storage mechanism.
Also, you probably cannot do what you want anyway. Assume
CONFIG_EXTRA_ENV_SETTINGS has a setting of BOOTDELAY to 5 seconds,
and you want to change it to 1 second only. with your code you have
the same variable definition twice in your default environment. Do
you know what the environment importer will do?
This is a valid concern and the biggest gap in the approach. I don't
have a full and proper solution for it currently, but have started
looking into a couple of ideas. In the meantime, I tried to draw
attention to it in the help text, essentially saying "here be dragons",
be careful.
There is intentionally no code using this feature, as meant in the
description it is intended to be reserved for the building user's
usage.
I think you are following a wrong approach. Such user specific
settings should IMHO loaded separately, either over serial like
(should be fast enough for a few hundred bytes) or from external
storage. "env import" is your friend.
I'm intentionally trying to have no persistent environment separate from
boot image.
The specific use case for which I'm using it is to ease building of
multiple otherwise identical images, embedding a fixed and well known
set of ethernet MAC addresses into each unique image for execution in
environments with no environment storage. It is meant to be used for
any
other values changed or added in the default image environment though
-
Editing files and building new images seems not the right method to
me. If each image is different, you will never ever be able to
reproduce which image has been installed where.
if there is a better way to accomplish this I'd be all for it, but I
couldn't find anything, thus the RFC patch.
There are many ways to provision code new hardware; depending on
hardware features more or less. You can always import envrionment
blobs from any device you can read from, including serial line
and (if available) network. You may be able to boot the system over
USB, you may use DFU, etc.
Changing the code and building a new image for each and every board
is pretty much pessimal.
Best regards,
Wolfgang Denk
Joel
