From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 05 Jul 2007 10:01:44 -0400 Subject: [U-Boot-Users] [PATCH 02/25] include/configs: Use new CONFIG_CMD_* in 82xx board config files. In-Reply-To: References: <468CEA10.50403@smiths-aerospace.com> Message-ID: <468CF9C8.6050809@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Jon Loeliger wrote: > So, like, the other day Jerry Van Baren mumbled: >>> >>> +/* >>> + * Command line configuration. >>> + */ >>> +#include >>> + >>> +#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. ;-)