From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Wed, 12 Nov 2008 17:31:01 +0100
Subject: [U-Boot] [PATCH] cmd_bdinfo: move implementation to
	arch	instead of common
In-Reply-To: <1aad82fa0811120817l163326adwec35a1ebeb08735@mail.gmail.com>
References: <1226436864-6377-1-git-send-email-plagnioj@jcrosoft.com>
	<491AE1E7.6080107@ge.com>
	<1aad82fa0811120817l163326adwec35a1ebeb08735@mail.gmail.com>
Message-ID: <20081112163101.GE7014@game.jcrosoft.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

 >
> > 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*.
It's the case
The idea is to allow soc and board to allow them to print more info

Best Regards,
J.