[U-Boot] Code style questions (weak functions, cpu/ v's lib_arch/)

[Mike Frysinger]

On Tuesday 18 November 2008 17:35:04 Graeme Russ wrote:
> 1) I have seen two varying applications of __attribute__ ((weak)) - The
> most common being of the form:
>
>   function(args) __attribute__((weak,alias("__function")));
>   __function(args)
>   {
>     /* Default functionality */
>   };
>
> The other is rare (occurs only 5 times in my slightly older code base)
>   __attribute__((weak))
>   function(args)
>   {
>     /* Default functionality */
>   };
>
> Is there any real difference between the two?

depends on how they're used.  the former gives you two symbols: one weak and 
one strong.  the latter gives you one weak symbol.  if you talk about tricky 
scenarios (like internal C library magic), then there would be a real case for 
the former.  in a static binary like u-boot, i dont believe there's any 
functional difference in the resulting binary.

> Is there a reason for the second one?

matter of style for the most part i think.  the former allows a whole bunch of 
symbols to be declared weak in one place.  the latter can require weak 
markings spread out over the source tree.

> 2) What defines if code belongs in cpu/<cpu_type> versus lib_<cpu_type>?
> Reset vector and bootstrap code is fairly obvious, but I notice that
> serial port functionality seems to be exclusively located in
> cpu/<cpu_type>, interrupt handling seems to be a bit of a mix depending on
> the particular cpu, lib_nios2\cache.S and lib_ppc\cache.c (to me) in an
> odd location.

it's lib_<arch>/ and cpu/<cpu>/, not lib_<cpu>.  architecture-level things go 
into lib_<arch>/ while cpu-specific things go into cpu/<cpu>/.  this probably 
gets pretty blurry in cases where there arent many cpu implementations for an 
arch.  like the NIOS.  but when you look at say ARM, each ARM cpu has 
drastically different behavior with things like the interrupt controller, or 
initial init, or resetting, but they all tend to be the same (or very similar) 
at the basic architecture level.

> Are there any hard and fast rules I should be using to increase the chances
> of these changes making it into mainline more smoothly?

i doubt it.  the only hard & fast rule is dont make Wolfgang disagreeable.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20081118/5e06d589/attachment-0001.pgp