All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH 02/25] include/configs: Use new CONFIG_CMD_* in 82xx board config files.
Date: Thu, 05 Jul 2007 10:01:44 -0400	[thread overview]
Message-ID: <468CF9C8.6050809@smiths-aerospace.com> (raw)
In-Reply-To: <E1I6RmZ-0002bd-MX@jdl.com>

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

      reply	other threads:[~2007-07-05 14:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-05  3:30 [U-Boot-Users] [PATCH 02/25] include/configs: Use new CONFIG_CMD_* in 82xx board config files Jon Loeliger
2007-07-05 12:54 ` Jerry Van Baren
2007-07-05 13:54   ` Jon Loeliger
2007-07-05 14:01     ` Jerry Van Baren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=468CF9C8.6050809@smiths-aerospace.com \
    --to=gerald.vanbaren@smiths-aerospace.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.