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

[Masahiro YAMADA]

Hi Alexey,



2015-01-14 17:18 GMT+09:00 Alexey Brodkin <Alexey.Brodkin at synopsys.com>:
> 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 ?

Weird. I can access the link.

The subject is
 [RFC] How to move lots of CONFIGs from header files to Kconfig


Another URL is
http://lists.denx.de/pipermail/u-boot/2014-October/193117.html


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

Yes, U-Boot is an open source project.
Anybody can contribute and it is very appreciated.

>  2) board maintainers are responsible for updates in defconfigs and
> corresponding headers in "include/configs/"

Yes. I expect this, but some board maintainers might not like to do it
for some reason.
( too busy, no interest , etc.)

At some point, we need to convert globally, I think.

>  3) that would be helpful if at (1) board maintainers are notified via
> direct emails on the change that has been done

Yes, good idea.


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

Yes, we can start with well-maintained 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.

Me neither.

I hesitate to drift apart from the Linux's Kconfig.


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

Indeed.

But we need to write 2 lines per CONFIG.  This is a disadvantage
against defconfig

config CMD_FOO
     default y


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

Agreed.

> 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).
>
> -Alexey
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Best Regards
Masahiro Yamada