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