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

[Jean-Christophe PLAGNIOL-VILLARD]

Hi Jerry,

On 09:02 Wed 12 Nov     , 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.  :-(

As you said it's a mess of ifdef this files and it's hard to understand and
to be sure which part we modify.
By splitting it, it will simplify arch implementation and maintaining.
BTW the header are already split for each in 'include/asm-arch/global_data.h'

>
> The centralized mess had no duplication of code, but a lot of #ifdef  
> ugly. 
in the c implmentation maybe but we already have in the header
>This patch trades off the removal of most of the #ifdef ugly for  
> a lot of duplication.  Which is the lesser of two evils?
Only 4 archs share actually the same code avr32, i386, mips and sh
which actually I've plan to modify for sh soon

>
> 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? 
why not in this case we will avoid a lots of ifdef
> 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). 
I prefer to have customizable code and update a manual than have hard maintaining code.
> 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.
We may need to write a guideline

Best Regards,
J.