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

[Wolfgang Denk]

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.

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?

> 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.

> 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

-- 
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
That's the thing about people who think  they  hate  computers.  What
they really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"