[U-Boot] [RFC PATCH 1/3] env: drop CONFIG_ENV_VARS_UBOOT_CONFIG support

[Stephen Warren <swarren@wwwdotorg.org>]

On 04/23/2014 06:03 AM, Masahiro Yamada wrote:
> On Tue, 22 Apr 2014 14:13:44 +0200
> Wolfgang Denk <wd@denx.de> wrote:
>> In message <1398159826-29398-2-git-send-email-yamada.m@jp.panasonic.com> you wrote:
>>> CONFIG_ENV_VARS_UBOOT_CONFIG, if defined, sets environment
>>> variables, "arch", "cpu", "board", etc. depending on
>>> CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_BOARD, respectively.
>>>
>>> We are discussing the introduction of Kconfig.
>>> In our discussion, we found boolean CONFIG macros are more useful
>>> in Kconfig context.
>>>
>>> That is,
>>>
>>> CONFIG_ARM=y
>>> CONFIG_CPU_ARMv7=y
>>> CONFIG_BOARD_HARMONY=y
>>> CONFIG_VENDOR_NVIDIA=y
>>>
>>> rather than
>>>
>>> CONFIG_SYS_ARCH="arm"
>>> CONFIG_SYS_CPU="armv7"
>>> CONFIG_SYS_BOARD="harmony"
>>> CONFIG_SYS_VENDOR="nvidia"
>>
>> I understand your intention - but does this not mean that we lose all
>> flexibility in assigning board and vendor names?  So far, we allow any
>> kind of names, lowercase and uppercase and mixed.  Will we not lose
>> this capability?  Also, we have '-' characters in a number of board
>> names - would this not also cause trouble?
>>
>> Finally, I don't see what your replacement code would be to create the
>> set of environment settigns - and I think these are needed, as some
>> user defined scripts are processing these?
> 
> The user who needs such environment setting can
> add them by using CONFIG_EXTRA_ENV_SETTINGS.
> 
> For example,
> 
> #define CONFIG_EXTRA_ENV_SETTINGS \
>    "arch=arm\0" \
>    "cpu=armv7\0" \
>    "soc=tegra20\0"
> 
> I am not sure this is acceptable.

Right now, we get the values set up automatically for free. It seems
like a regression to force the board maintainer to set these all up
manually instead.

Kconfig supports string variables. The Linux kernel stores the ARM
debug_ll include filename in one for example. Perhaps using that
technique would resolve the issue.