public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jon Loeliger <jdl@jdl.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 08:54:07 -0500	[thread overview]
Message-ID: <E1I6RmZ-0002bd-MX@jdl.com> (raw)
In-Reply-To: Your message of "Thu, 05 Jul 2007 08:54:40 EDT." <468CEA10.50403@smiths-aerospace.com>

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

  reply	other threads:[~2007-07-05 13:54 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 [this message]
2007-07-05 14:01     ` Jerry Van Baren

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=E1I6RmZ-0002bd-MX@jdl.com \
    --to=jdl@jdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox