[U-Boot] [PATCH 1/2] common: mark commands as default to match "config_cmd_default.h"

Simon Glass
2015-01-15T14:46:16Z

Hi,

On 14 January 2015 at 01:18, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
> Hi Simon, Masahiro-san,
>
> On Tue, 2015-01-13 at 20:18 -0800, Simon Glass wrote:
>> >
>> >> Probably I'm missing details of our Kconfig migration plan if one
>> >> exists. Then I'd like to get a reference to the plan so I'm not
>> >> attempting to do things that are already scheduled and could be even in
>> >> a process of implementation.
>> >> Otherwise if there's no current plan for Kconfig migration we may start
>> >> discussion on how to deal with "commands" in particular.
>> >
>> >
>> > I proposed the following way, but no big conversion movement has happened yet.
>> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/199965/focus=200089
>> >
>> > If you have an idea, please propose it.
>
> Unfortunately I cannot open this link - I see "Connection to 80.91.229.5
> failed". Do you mind to provide a link for the same message in
> http://lists.denx.de ?
>
>
>> > Kconfig conversion is a too big task to be done by a single indivisual.
>> > Any suggestion, any form of contribution is very appreciated.
>
> Indeed and that stops me from starting this work as well.
> So my point is:
> 1) anybody may do updates to Kconfig like add more U-Boot commands,
> some settings (CONFIG_SYS_xxx)
> 2) board maintainers are responsible for updates in defconfigs and
> corresponding headers in "include/configs/"
> 3) that would be helpful if at (1) board maintainers are notified via
> direct emails on the change that has been done
>
>> > I personally keep away from any global changes until
>> > non-generic boards are dumped.
>> >
>> > As Tom said in the following mail,
>> > http://lists.denx.de/pipermail/u-boot/2015-January/201032.html
>> > we are going to remove lots of boards.
>> >
>> > I do not want to make extra efforts on non-generic boards.
>
> That makes sense but why don't we start implementation of changes in
> good boards we know already converted to "generic"? There're even entire
> arches that switched to "generic boards".
>
>> >> The point is commands are low-hanging fruits in terms of Kconfig
>> >> migration - there're no extra options and tweaks, once all commands are
>> >> added in Kconfig (essentially with dependencies etc) we may clean all
>> >> board headers. The only real problem here is amount of work - lots of
>> >> headers/defconfigs to patch. But still this is doable.
>> >
>> >
>> > I realized one problem when I was doing this task
>> > for my boards in commit 25e274e20208.
>> >
>> > The defconfigs of my boards are almost the same:
>> > (configs/ph1_ld4_defconfig, configs/ph1_pro4_defconfig, configs/ph1_sld8_defconfig)
>> >
>> > What is inconvenient as for defconfig is that
>> > it does not support "include" directive like C headers.
>> >
>> > People generally like to add CONFIG_CMD_* to a common header file
>> > such as include/configs/tegra-common.h
>> >
>> > On the other hand, on defconfig, we must touch each defconfig of the board family.
>> >
>> > I have not been able to decide right direction to solve this issue.
>> >
>> > I think we need to discuss about how to live with lots of defconfigs.
>>
>> How about this:
>>
>> 1. Support an 'include' option in defconfig to include another file.
>> This could take the form of CONFIG_DEFCONFIG_INCLUDES (comma-separated
>> list of filenames). Don't allow nested includes - this CONFIG provides
>> a complete list of includes.
>> 2. When you use menuconfig to edit the config, it ignores the include
>> and just writes out everything. Then it runs a simple script which
>> parses the include files, and adjusts the file so that things in the
>> includes are not repeated in the defconfig.
>>
>> I think this scheme would be good enough, but can probably be
>> improved. At least it would be better than what we have.
>>
>> Or we could instead define particular includes for different purposes:
>>
>> - Arch
>> - SOC
>> - SOC Vendor
>> - Board vendor
>> - Board family
>>
>> We could then require that standard filenames are used, and search for
>> the correct file based on the SOC/board/vendor setting, etc.
>>
>> As an example, for trimslice, we could search for arm.h, tegra.h,
>> nvidia.h, compulab.h, some_family_name.h.
>>
>> This is less flexible though.
>
> Frankly I don't like this approach with post-processing steps. It will
> inevitably end-up with messed up configs.
>
> Why don't we just use default values in Kconfig for ARCH/SOC/Board?
> It's pretty obvious that 1 board may have N flavors but then have a
> baseline options selected in "board/vendor/board_name/Kconfig" and only
> put options that differ between boards in your defconfigs.
>
> This way "savedefconfig" will automatically strip down all extra lines
> for a particular board.
>
> This is how things work in Linux kernel and Buildroot Kconfig-based
> build systems. Probably I'm missing something here because U-Boot
> differs from mentioned projects in some aspects - if so please correct
> me.

I started with this approach and Masahiro was not very keen on it. I'm
OK with it, particularly as it is already supported, but I wonder
whether we can do better.

I notice that some kernel distributions have a script which pulls out
common kernel configs in a separate file (e.g. for ARM, or for Tegra)
for checking into source control, then combine them again for the
kernel. This suggests that others have this problem too. It does seem
like a convenient feature to be able to have some sort of hierarchy of
config.

Re messed-up configs, what will mess up? We can make it part of
writing the config, perhaps.

>
>> >>
>> >> That's a separate topic. I do agree that CMD_FPGA makes not much sense
>> >> for most of boards, as well as some others.
>> >>
>> >> And I think during migration process of commands to Kconfig it's a good
>> >> time to reconsider default commands.
>> >
>> > Agree.
>> > We should reconsider the default.
>> > In my opition, most of the ones in config_cmd_default.h are not default commands.
>
> Right but if we expect to switch to Kconfig solely for commands
> selection we may not care much about contents of "config_cmd_default.h"
> assuming it will go away sometime soon.
>
> Probably we may just focus on:
> 1. Add all existing commands in Kconfig
> 2. Select very few of them to be globally default
>
> (1) is pretty simple and anybody may do it if time permits
> (2) requires wide discussion
>
> But what's really nice with Kconfig is its "savedefconfig". So we may
> not set any commands as globally default and let every architecture,
> board or defconfig to select really required options.
>
> Then once any option is marked as global (or even arch or board) default
> in a matter of simple script that does "make XXX_defconfig && make
> savedefconfig && mv defconfig configs/XXX_defconfig" all relevant
> defconfigs will be correctly updated (default options will be stripped
> out).

Yes, it would be great to get all command configs into Kconfig.

I wonder if we need a script which automates the conversion? The
header file includes in the include/configs/... files makes this
non-trivial. But if we had a script which could take a CONFIG as a
parameter, remove it from all config headers, and add it to relevant
defconfigs, it would be very useful.

Regards,
Simon