Hi 2015-01-15 23:46 GMT+09:00 Simon Glass <s...@chromium.org>: > Hi, > > On 14 January 2015 at 01:18, Alexey Brodkin <alexey.brod...@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.
Honestly, I do not like baseline options in board-Kconfig very much. The advantage is that it works without any change. What I suggested before was to use scripts/kconfig/merge_config.sh. For example, put the SoC baseline options into tegra30_defconfig. Put the difference from that into tegra30_(board).config For example, make tegra30_defconfig tegra30_seaboard.config make tegra30_defconfig tegra30_trimslice.config The disadvantage is that we would have to input more for the configuration and has some impact on other projects such as BuildRoot... Another option is "multi-image". Actually barebox adopted this solution to solve the increasing defconfig problem. In barebox, for example, all the Tegra boards share a single defconfig, "tegra_v7_defconfig" tegra_v7_defconfig creates images for beaver, jetson, colibri, ac100, ... It takes advantage of Device Tree configuration and garbage collection. So, it generates multipule images without increasing memory foot-print. > 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. The hierarchical config strategy makes "savedefconfig" difficult , I think. >> >>> >> >>> >> 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. I have a Python script that moves each CONFIG from header files to defconfig files. I wrote it for my local use, so it might not be very clean. If necessary, I can share it on ML. -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot