[U-Boot] [PATCH v2 3/4] kconfig: switch to single .config configuration

[Masahiro YAMADA]

Hi Stephen,


2015-02-20 6:13 GMT+09:00 Stephen Warren <swarren at wwwdotorg.org>:
> On 02/19/2015 12:55 AM, Masahiro Yamada wrote:
>>
>> When Kconfig for U-boot was examined, one of the biggest issues was
>> how to support multiple images (Normal, SPL, TPL).  There were
>> actually two options, "single .config" and "multiple .config".
>> After some discussions and thought experiments, I chose the latter,
>> i.e. to create ".config", "spl/.config", "tpl/.config" for Normal,
>> SPL, TPL, respectively.
>>
>> It is true that the "multiple .config" strategy provided us the
>> maximum flexibility and helped to avoid duplicating CONFIGs among
>> Normal, SPL, TPL, but I have noticed some fatal problems:
>>
>> [1] It is impossible to share CONFIG options across the images.
>>    If you change the configuration of Main image, you often have to
>>    adjust some SPL configurations correspondingly.  Currently, we
>>    cannot handle the dependencies between them.  It means one of the
>>    biggest advantages of Kconfig is lost.
>>
>> [2] It is too painful to change both ".config" and "spl/.config".
>>    Sunxi guys started to work around this problem by creating a new
>>    configuration target.  Commit cbdd9a9737cc (sunxi: kconfig: Add
>>    %_felconfig rule to enable FEL build of sunxi platforms.) added
>>    "make *_felconfig" to enable CONFIG_SPL_FEL on both images.
>>    Changing the configuration of multiple images in one command is a
>>    generic demand.  The current implementation cannot propose any
>>    good solution about this.
>>
>> [3] Kconfig files are getting ugly and difficult to understand.
>>    Commit b724bd7d6349 (dm: Kconfig: Move CONFIG_SYS_MALLOC_F_LEN to
>>    Kconfig) has sprinkled "if !SPL_BUILD" over the Kconfig files.
>>
>> [4] The build system got more complicated than it should be.
>>    To adjust Linux-originated Kconfig to U-Boot, the helper script
>>    "scripts/multiconfig.sh" was introduced.  Writing a complicated
>>    text processor is a shell script sometimes caused problems.
>>
>> Now I believe the "single .config" will serve us better.  With it,
>> all the problems above would go away.  Instead, we will have to add
>> some CONFIG_SPL_* (and CONFIG_TPL_*) options such as CONFIG_SPL_DM,
>> but we will not have much.  Anyway, this is what we do now in
>> scripts/Makefile.spl.
>>
>> I admit my mistake with my apology and this commit switches to the
>> single .config configuration.
>>
>> It is not so difficult to do that:
>>
>>   - Remove unnecessary processings from scripts/multiconfig.sh
>>    This file will remain for a while to support the current defconfig
>>    format.  It will be removed after more cleanups are done.
>>
>>   - Adjust some makefiles and Kconfigs
>>
>>   - Add some entries to include/config_uncmd_spl.h and the new file
>>     scripts/Makefile.uncmd_spl.  Some CONFIG options that are not
>>     supported on SPL must be disabled because one .config is shared
>>     between SPL and U-Boot proper going forward.  I know this is not
>>     a beautiful solution and I think we can do better, but let's see
>>     how much we will have to describe them.
>>
>>   - update doc/README.kconfig
>>
>> More cleaning up patches will follow this.
>
>
>> diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig
>> b/arch/arm/cpu/armv7/tegra-common/Kconfig
>> index 0de13ae..c9e8919 100644
>> --- a/arch/arm/cpu/armv7/tegra-common/Kconfig
>> +++ b/arch/arm/cpu/armv7/tegra-common/Kconfig
>> @@ -26,7 +26,7 @@ config SYS_MALLOC_F_LEN
>>         default 0x1800 if SYS_MALLOC_F
>>
>>   config USE_PRIVATE_LIBGCC
>> -       default y if SPL_BUILD
>> +       default y
>>
>>   config DM
>>         default y if !SPL_BUILD
>
>
> I think the above patch demonstrates the problem very nicely; it changes the
> semantics from having CONFIG_USE_PRIVATE_LIBGCC enabled only in SPL build to
> having it enabled everywhere. While that particular change shouldn't be an
> issue, I think that requiring that all config options to have the same value
> in main/SPL/TPL will be.

Right.  This is the disadvantage of the single .config strategy.
That's why I chose separate .config at first.


> For example, how do we disabled MMC support in SPL?
> We have to introduce separate CONFIG_MMC and CONFIG_SPL_MMC don't we?

Yes, I expect this.

We already have
CONFIG_SPL_MTD_SUPPORT
CONFIG_SPL_NAND_SUPPORT
CONFIG_SPL_NET_SUPPORT
CONFIG_SPL_USB_HOST_SUPPORT
etc.


> That doesn't seem any better than having separate defconfig files for
> SPL/non-SPL, or using ifdefs in a single defconfig file. What happened to
> the ability of one defconfig file to include another, so options could be
> shared between the two?


What you are saying is right, but
we are suffering from various problems that are ascribed to the multi
.config way.

I cannot suggest any solution but the single .config.


-- 
Best Regards
Masahiro Yamada