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

[Simon Glass]

Hi,

On 24 February 2015 at 23:14, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> Hi Scott,
>
>
> On Tue, 24 Feb 2015 18:17:59 -0600
> Scott Wood <scottwood at freescale.com> wrote:
>
>> On Tue, 2015-02-24 at 16:20 +0900, Masahiro Yamada wrote:
>> > Hi Scott,
>> >
>> >
>> > On Mon, 23 Feb 2015 19:22:51 -0600
>> > Scott Wood <scottwood at freescale.com> wrote:
>> >
>> > > 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:"...
>> >
>> > Yes, it can as for "make *_defconfig".
>> >
>> > If we modify some options in .config for example by "make menuconfig",
>> > we also modify some in spl/.config correspondingly.
>> >
>> > Users are responsible for configure .config and spl/.config in sync
>> > in the sane combination.
>> >
>> >
>> >
>> > > 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?
>> >
>> > To have independent symboles coexist in a single .config,
>> > I can only suggest to duplicate options like
>> > CONFIG_FOO=0x100
>> > CONFIG_SPL_FOO=0x200
>> > CONFIG_TPL_FOO=0x300
>>
>> What I meant was a way to keep the configs separate, but automatically
>> import the CONFIG_FOO from the SPL .config as CONFIG_SPL_FOO (or some
>> other prefix that doesn't conflict with SPL-specific options).
>
> What is the benefit of doing this?
>
>
>
>
>
>> > > 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.
>> >
>> > I guess it is possible for boolean options,
>> > but impossible to set hex/int options independently.
>>
>> How many hex/int options are there, that need to be different in SPL
>> versus the main U-Boot?  Having a few CONFIG_SPL_xxx for those is better
>> than having a bunch.
>
> OK.
> But, I do not think we need to tweak the Kconfig just for saving boolean options.
>
>> > BTW, Ian's idea had been already achieved by include/config_uncmd_spl.h
>>
>> So, the answer is to avoid kconfig and go back to using the preprocessor
>> for configuration? :-(
>
> I am not saying I prefer the preprocessor.
>
> Indeed, include/config_uncmd_spl.h is ugly,
> so I'd like to propose a better solution.
>
> If we introduce CONFIG_SPL_DM, for example, the ifdef conditional in source files
> will be like this:
>
>    #if  (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_DM)) || \
>               (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_DM))
>
>               [Driver Model Code]
>
>    #else
>               [Non Driver Model Code]
>    #endif
>
> This is too ugly to be written in each conditional.
>
>
> So, I want to describe like this:
>
>     #if IS_ENABLED_CONFIG(DM)
>           [Driver Model Code]
>     #else
>           [Non Driver Model Code]
>     #endif
>
> I will post some patches later on.

BTW it would be nice if we could compile the code even if it is not
included (e.g with the compile-time IS_ENABLED(CONFIG_...)). Also for
driver model I would like it to be supported the same in both SPL and
U-Boot proper, to avoid this sort of thing. We are very close to
merging the driver model SPL support.

[snip]

Regards,
Simon