[U-Boot] [RFC] How to move lots of CONFIGs from header files to Kconfig

Nikita Kiryanov
2014-10-27T17:41:47Z

Hi Masahiro,

On 27/10/14 19:13, Masahiro YAMADA wrote:
> Hi.
>
> I've been thinking how to move so many CONFIGs to Kconfig.
>
> First, I want to move many boolean macros such as CONFIG_CMD_*,
> because it seems easier than string, int, hex configs.
>
> Roughly, we have two options, I think.
>
>
>
> [1] I do this work for all the boards
>
> I will prepare many entries in Kconfigs and
> also move lots of configs options by a tool.
>
> Pros:
> - Possible to move many options at one time
>
> Cons:
> - Cause lots of conflicts
> - It is pointless to touch lots of unmaintained boards
> that might be removed by the end of this year
> - Hard work for me
>
> [2] Each board maintainer takes care of boards he is responsible for.
>
> Procedure:
>
> 1. I will create many entries in Kconfigs
> without dependencies ("depends on" and "select")
>
> 2. Each board maintainer will move config options
> from his board headers to defconfigs (*)
> (I expect most of active boards will be switched at this step.)
>
> 3. Many of unmaintained boards ( = not converted to generic board)
> will be removed by the end of this year.
>
> 4. I will forcibly convert left-over boards.
> These boards are almost inactive, so this conversion
> will not produce much conflicts.
>
> 5. Implement "depends on" and "select" correctly
>
> (*) You can edit directly configs/foo_defconfig.
> Or you can use Kconfig functions in case you may introduce a typo.
>
> Run "make foo_defconfig"
> Run "make menuconfig"
> Enable config options you like
> Select "Save".
> Run "make savedefconfig"
> Run "mv defconfig configs/foo_defconfig"
> Remove unnecessay CONFIGs from your board header files
>
>
> Pros:
> - Reduce the possibility of significant conflicts
> - Avoid needless efforts for unmaintained boards
>
> Cons:
> - Patch for each board will fly around
> - Take longer time
>
>
> At first, I was planning to do [1] but it would disturb the
> development on SoC subsystems.
> I see SUNXI custodians are touching their Kconfigs and defconfigs very often.
> [1] would cause conflicts between u-boot/master and u-boot-sunxi/{master,next}.
> I also many boards are being dropped these days, which increase the conflicts.
>
>
>
> I am thinking [2] is better.
> Comments are welcome.
>

I recently tried to do [1] for a bunch of SPL #defines, and the attempt
ended in me git stashing the whole thing and putting it off for a later
date. The amount of work this approach requires feels very prohibitive,
and I agree that it is likely to be disruptive, so I'm in favour of
[2] as well.

--
Regards,
Nikita Kiryanov