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

[Jason]

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,
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?

thx,

Jason.