Hi Simon,
Le 22/10/2011 18:40, Simon Glass a écrit :
Hi Albert,
On Sat, Oct 22, 2011 at 12:17 AM, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Le 22/10/2011 07:11, Simon Glass a écrit :
Hi,
Each architecture has its own board.c but they are mostly quite similar.
New features such as fdt, boot timing, trace, profiling, etc. must be done separately for each arch, even if there are no architecture-specific bits.
What would you say to adding something like lib/board.c which is a simplified cleaned-up copy of one of the existing board.c files, and a CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the architecture-specific one. Then perhaps people could try it out and we could slowly move to it over time...
I'd say anything that factorizes ARM code is a good thing. :)
However I'm not in favor of a CONFIG option that would force the board code to provide some functions just in odrer to override one, not if weak
My suggestion was:
CONFIG_ARCH_GENERIC_BOARD - you get lib/board.c not CONFIG_ARCH_GENERIC_BOARD - you get arch/xxx/lib/board.c
definitions can do a finer job. I am looking into that already for cache management function specialization, and it seems like there is the same kind of possibility here, with lib functions defined weak and the board code overriding the ones it deems necessary to.
ok. Just one little point. Weak symbols are the punishment our C++ overlords gave us for not having to understand what code is executed when we instantiate a C++ subclass. It is nice to know what code is being linked in and avoid having to disassemble to find out. I think using weak symbols to avoid a OBJS-$(CONFIG_ARCH_GENERIC_BOARD) in a couple of Makefiles risks going too far.
The problem I see with a config option is that it is all-or-nothing: either all cache functions are defined at the lib level, or none is. I want a finer-grain, function-by-function, approach. For the moment I think weak symbols are a nice solution, although I do recognize that it will be less visible than configuration options.
Regards, Simon
Amicalement,