[U-Boot] [PATCH v3 5/7] kconfig: switch to single .config configuration

[Scott Wood <scottwood@freescale.com>]

On Fri, 2015-02-20 at 14:24 +0900, 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.

Sharing can happen in the defconfig with "+S:"...

What sort of dependencies are people wanting?  Would it be possible to
modify kconfig to import SPL .config into the main config (or vice
versa?) with a name prefix so that dependencies could happen, without
sacrificing the ability to set symbols independently?

Or as Ian suggested, have only the main config be user-editable, but
still let select/depends turn certain things on/off for the
auto-generated SPL config.

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

How about defconfig fragments?  Instead of having script infrastructure
specifically for CONFIG_SPL_FEL, merge a fragment containing
"+S:CONFIG_SPL_FEL".

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

It seems like the root cause of this sprinkling is wanting to use
default y to avoid touching a bunch of defconfig files, but not wanting
to do the default y at the toplevel Kconfig.  Maybe better tooling for
bulk defconfig updates would help.  In any case, couldn't you do
CONFIG_SPL_DM currently, by making DM depend on "!SPL_BUILD || SPL_DM",
without fundamentally changing the SPL kconfig infrastructure?

Why do symbols like LOCALVERSION and CC_OPTIMIZE_FOR_SIZE depend on !
SPL_BUILD?

> [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 had been hoping that the split configs would let us get rid of many of
the CONFIG_SPL_* options that we already have.

How will TPL be handled?  Are you going to duplicate all the SPL
symbols?  Or just avoid ever kconfigizing them?

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

How is uncmd_spl better than "!SPL_BUILD"?

-Scott