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@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.