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.