[U-Boot] [RFC] ARM ISA/cpu/SoC code organization for cache and other functions

[Albert ARIBAUD]

Le 16/09/2011 01:18, Jason a écrit :
> On Thu, Sep 15, 2011 at 07:10:49PM -0400, Jason wrote:
>> Albert,
>>
>> On Thu, Sep 15, 2011 at 11:42:12PM +0200, Albert ARIBAUD wrote:
>>> (re-posting cleaned up and outside any other discussion)
>>>
>>> This RFC is for discussing how cache operation functions should be
>>> managed in the ARM tree.
>> ...
>>> The source code implementation for ARM cache ops would be:
>>>
>>> - a header file declaring the ops as weak C functions for at least full
>>> cache flush, full cache invalidate, cache line flush and cache line
>>> invalidate;
>>>
>>> - SoC-specific, cpu-specific, and isa-specific definitions for these
>>> functions, in the form of C files.
>>>
>>> - a default implementation in a lib/ file.
>>>
>>> The object files shall be linked in decreasing precedence order, i.e.
>>> SoC file first, then cpu file, then isa file, then lib last, so that for
>>> each cache op, the weak symbol mechanism uses the most specific one.
>>>
>>> One possible organisation for files would be (switch to fixed size font)
>>>
>>>           (isa)   (cpu)     SoC)
>>> arch/arm
>>>           /armv5t/
>>>                   cache-ops.c
>>>                   arm926ejs/
>>>                             cache-ops.c
>>>                             orion5x/
>>>                                     cache-ops.c
>>>
>>> Plus of course arch/arm/lib/cache-ops.c.
>>
>> As a new-comer to the u-boot code, is there a difference between this
>> implementation and say, a struct of function pointers?  eg the struct
>> would default to armv5t ops, and arm926ejs init could redefine, say,
>
> s/redefine/reassign/
>
>> cache line invalidate.
>>
>> The reason I ask is that I think the struct of function pointers would
>> be easier for new folks to sort out with cscope, et al.  Whereas, the
>> weak declarations with multiple implementations would muddy the waters
>> when learning the code.
>>
>> Am I missing something?  What are the advantages of weak declarations
>> over redefined function pointers?

At first sight, implementing weak symbols through pointers might look 
more understandable because is leverages on C concepts such as pointers, 
which are better known than weak symbols.

However, the simplicity of the base concept must be paid for, in 
complexity of handling: you need to initialize these pointers, you need 
to make sure they are initialized the right way, and that no 
initialization is missed.

You also pay in performance, as each access to the weak symbol means a 
pointer indirection.

Last, and not least, the concept of weak symbols is purely a link-time 
question ; it is only one variant in the ways the linker determines the 
value of each symbol. Why, then, implement it in run-time?

So yes, you could re-implement weak symbols at run time with (arrays of) 
pointers, but you would not gain clarity overall, and you would distract 
the reader's attention from what is actually going on by explicitly 
interposing an implementation.

OTOH, weak symbols, as implemented by gcc, simply tell the linker that 
if a symbol is defined more than once, the linker should do nothing 
rather than complain, and keep the first definition. End of story. :)

I *think* what worries you is that when defining a weak symbol, you 
don't necessarily tell the reader that this symbol is weak, and he might 
have a hard time finding out. That's a valid point: although the symbol 
also has a declaration which explicitly says it is weak, the reader 
might not look up that declaration. But the solution is easy: just add a 
C comment before the symbol, reminding the reader that the symbol is 
weak and why it is, and/or referring him/her to the ./doc/README.xxx 
file which explains it.

>> thx,

You're welcome.

>> Jason.

Amicalement,
-- 
Albert.