
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. ;-)