[U-Boot] A bit about board.c, board.c

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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,
-- 
Albert.