[U-Boot] [PATCH] cmd_bdinfo: move implementation to arch instead of common

[Mike Frysinger]

On Wed, Nov 12, 2008 at 9:02 AM, Jerry Van Baren wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>> ---
>> apply after my precedent fix for cmd_bdinfo
>>
>> Best Regards,
>> J.
>>  common/Makefile         |    1 -
>>  common/cmd_bdinfo.c     |  447 -----------------------------------------------
>>  include/common.h        |   15 ++
>>  lib_arm/Makefile        |    1 +
>>  lib_arm/bdinfo.c        |   69 ++++++++
>>  lib_avr32/Makefile      |    1 +
>>  lib_avr32/bdinfo.c      |   62 +++++++
>>  lib_blackfin/Makefile   |    1 +
>>  lib_blackfin/bdinfo.c   |   68 +++++++
>>  lib_i386/Makefile       |    1 +
>>  lib_i386/bdinfo.c       |   62 +++++++
>>  lib_m68k/Makefile       |    1 +
>>  lib_m68k/bdinfo.c       |  101 +++++++++++
>>  lib_microblaze/Makefile |    1 +
>>  lib_microblaze/bdinfo.c |   65 +++++++
>>  lib_mips/Makefile       |    1 +
>>  lib_mips/bdinfo.c       |   62 +++++++
>>  lib_nios/Makefile       |    1 +
>>  lib_nios/bdinfo.c       |   61 +++++++
>>  lib_nios2/Makefile      |    1 +
>>  lib_nios2/bdinfo.c      |   71 ++++++++
>>  lib_ppc/Makefile        |    1 +
>>  lib_ppc/bdinfo.c        |  141 +++++++++++++++
>>  lib_sh/Makefile         |    1 +
>>  lib_sh/bdinfo.c         |   62 +++++++
>>  lib_sparc/Makefile      |   13 +-
>>  lib_sparc/bdinfo.c      |   78 ++++++++
>
> Hi Jean-Christophe,
>
> Is this a good idea?  It takes one centralized mess (that is deprecated,
> but we don't have a good track record of death after deprecation) and
> spreads it out over a bunch of files.  Reminds me of cancer.  :-(
>
> The centralized mess had no duplication of code, but a lot of #ifdef
> ugly.  This patch trades off the removal of most of the #ifdef ugly for
> a lot of duplication.  Which is the lesser of two evils?
>
> If you continue down the fragmentation path, would it work to keep the
> primary bdinfo command (cmd_bdinfo.c) and add two weak function calls to
> it that processor families and boards can hook to add in their extra
> processor- and board-specific stuff?  This may result in some
> rearrangement of the print output (which I don't view as a problem, but
> manual writers might not like it).  It also results in some additional
> obscurity since a processor/board porter needs to understand that there
> is an additional hook to grab for customization.

i think the split version proposed is a lot nicer than the current
one, but going the route of having an arch hook would be best.  i dont
think we even need a weak function ... force every arch to implement
*something*.
-mike