[U-Boot-Users] [PATCH 02/25] include/configs: Use new CONFIG_CMD_* in 82xx board config files.

[Jerry Van Baren]

Jon Loeliger wrote:
> So, like, the other day Jerry Van Baren mumbled:
>>>  
>>> +/*
>>> + * Command line configuration.
>>> + */
>>> +#include <config_cmd_all.h>
>>> +
>>> +#undef CONFIG_CMD_BEDBUG
>>> +#undef CONFIG_CMD_BMP
>>> +#undef CONFIG_CMD_BSP
>> ...
> 
> 
>> This isn't your fault, Jon, but the command definition methodology in 
>> the 82xx is Very Very Bad[tm].
> 
> Um, yeah, I saw that too. :-)
> 
>> It is defining *ALL* commands and then selectively undefining specific 
>> ones.  I tried to rebuild for my 8272ADS board and noticed the build 
>> broke because someone added a command which was incompatible with it, 
>> and the above methodology picked up the new command by default.
>>
>> BAD.  VERY VERY BAD.
> 
> So, I've been pretty faithful in following the command selection
> that is already in the board files so far.  As you have noticed,
> one of the effects of this work is that we get to more easily
> identify, um, oportunities for improvment...
> 
> And yes, I am absolutely relying on _other_ people to test
> this set of changes!  I've been checking some of the PowerPC
> boards, but that's really all I can do here...
> 
>> I added "fix stupid command configuration" to my job jar, but my job jar 
>> is pretty full.  :-(  If someone else has an empty job jar (yeah, that 
>> was a joke ;-) and incentive, this would be a profitable cleanup.  I 
>> contend that the proper configuration would be to use the "normal" 
>> command configuration and then add whatever missing "abnormal" ;-) 
>> commands are desired.  This is a much safer and saner way.
> 
> Right.  My plan is this:
> 
>     1) Continue with the remaining board config
>        files I've not converted yet.
>     2) Drink.
>     3) Remove uses of CONFIG_COMMAND from the _entire_
>        rest of the code base.
>     4) Drink.
>     5) Cleanup stragglers, fix typos (!), READMEs, etc.
>     6) Profit.
> 
> I would encourage folks to read through their favorite config files
> in the testing tree and make sure it is sane, compiles, or even boots.
> If you want to then fix stuff, please submit it against "testing" so
> we can be pretty sure it is working there before pulling it into
> the mainline repo.
> 
>> Is there a good reason to have an config_cmd_all.h "all commands" 
>> definition?  If not, I propose we remove it and _properly_ fix the 
>> breakage that ensues.
> 
> I'm not convinced there is, long term.  However, like I said,
> I am currently doing the straight-forward conversion right now.
> We can (and should) fix the fallout.  I am in favor of removing
> the "config_cmd_all.h" file. That would be step 5), above.
> 
>> I would further propose that, assuming Jon is willing, he be authorized 
>> to fix the above listed boards with wrongly configured command sets by 
>> simply setting their command set to the "normal" command set.
> 
> And in the meantime, patches against the testing repo are welcome too!
> 
>> gvb
>> P.S. Sorry for volunteering you, Jon.  Keep up the good work. :-)
> 
> I hear you. :-)
> 
> jdl

ACK on the "all commands" cleanup being part of Step 5.  My proposal 
would short-circuit the orderly process.  :-(

gvb
P.S. I'll split the work with you, I'll do the even steps and you can do 
the odd steps.  ;-)