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 <[EMAIL PROTECTED]> >> --- >> 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot