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

[Masahiro Yamada <yamada.m@jp.panasonic.com>]

Hi Alexey,


On Fri, 9 Jan 2015 20:09:22 +0000
Alexey Brodkin <Alexey.Brodkin@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.Brodkin@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