Hi Alexey,
On Fri, 9 Jan 2015 20:09:22 +0000 Alexey Brodkin <alexey.brod...@synopsys.com> wrote: > Hi Masahiro-san, > > On Tue, 2015-01-06 at 00:34 +0900, Masahiro YAMADA wrote: > > Hi Alexey, > > > > 2015-01-03 22:20 GMT+09:00 Alexey Brodkin <alexey.brod...@synopsys.com>: > > > Now when we may select commands via menuconfig let's adjust default > > > settings with "config_cmd_default.h". > > > > > > As the next step we may get rid of "config_cmd_default.h" inclusion in > > > "include/configs/*.h" and "config_cmd_default.h" itself. > > > > Thanks for working on this, but I think this patch changes the behavior. > > > > Some boards include <config_cmd_default.h> and then undefine > > unnecessary commands. > > > For example, include/configs/snapper9260.h > > > > #include <config_cmd_default.h> > > #undef CONFIG_CMD_BDI > > #undef CONFIG_CMD_FPGA > > #undef CONFIG_CMD_IMI > > #undef CONFIG_CMD_IMLS > > #undef CONFIG_CMD_LOADS > > #undef CONFIG_CMD_SOURCE > > > > If you set the default value to "y" in Kconfig, > > it cannot be undef'ed by C-headers. > > That's true. > But anyway at some point we'll need to switch selection of commands in > Kconfig, right? Yes. > 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. Kconfig conversion is a too big task to be done by a single indivisual. Any suggestion, any form of contribution is very appreciated. 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. > 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. > > > config CMD_BDI > > > bool "bdinfo" > > > + default y > > > help > > > Print board info > > > > > > This change enables CMD_BDI for all the boards. > > > > Please notice the following boards do not want to compile this command. > > > > ./include/configs/dbau1x00.h:#undef CONFIG_CMD_BDI > > > > @@ -193,6 +204,7 @@ config CMD_USB > > > > > > config CMD_FPGA > > > bool "fpga" > > > + default y > > > help > > > FPGA support. > > > > Moreover, I doubt some of default commands in <config_cmd_default.h> > > (I have used only some of commands in <config_cmd_default.h>) > > > > For example, it seems weird to enable CONFIG_CMD_FPGA by default. > > > > I do not think most of boards have FPGA. > > 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. > I will highly appreciate input on both topics from others so we'll do > some progress here and will make sure all parties are happy. > > -Alexey Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot