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

Jean-Christophe PLAGNIOL-VILLARD plagnioj at jcrosoft.com
Wed Nov 12 19:08:40 CET 2008


On 12:55 Wed 12 Nov     , Mike Frysinger wrote:
> On Wed, Nov 12, 2008 at 11:31 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> > 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
> 
> so you have one hard arch hook and one weak board hook.  every
two weak hook to allow board AND soc to print more info

Best Regards,
J.


More information about the U-Boot mailing list