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

[Mike Frysinger]

On Wed, Nov 12, 2008 at 1:08 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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

there's no point in making the arch one weak if every arch implements
it.  you simply add useless overhead.

> to allow board AND soc to print more info

which is exactly what i said
-mike