[RFC PATCH] Provide mechanism for build-time default env entries

[Joel Johnson]

On 2020-01-20 11:59, Wolfgang Denk wrote:
> Dear Joel,
> 
> In message <7cac871967a1317cea251e78d67a30ac at 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