Hi Alexey,
2015-01-14 17:18 GMT+09:00 Alexey Brodkin <alexey.brod...@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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot