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

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

[Graeme Russ]

Further to my question regarding weak functions versus conditional compile,
I have a couple of other 'style' questions:

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? Is there a reason for the
second one?

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.

The reason I ask is that as part of my restructure of i386 / sc520, I want to
make sure the right code ends up in the right place. A couple of examples:
- Standard i386 interrupt handling uses 8259 PICs - This is an architectural
  thing, a not a hard and fast i386 cpu implementation. The sc520 has a more
  advanced on-chip PIC allowing up to 22 interrupts and dynamic routine of
  interrupt sources to interrupt priorities.
- The sc520 has a some very nice on-chip timers, i386 requires external
  timers and/or calibrated delay loops

So I am thinking to leave all _very_ i386 CPU specific code (reset vector,
bootstrap, real-to-protected mode switch, IDT, etc) in cpu/i386/ and create
a new cpu/i386/sc520/ folder for _very_ sc520 specific code (memory mapped
configuration register control, memory sizing). These two folders will
basically have all the low level assembler code.

I was then going to move timer control, PIC setup, and serial I/O into
lib_i386/ (and possible creating a sub folder lib_i386/sc520/ to hold the
sc520 specific timer, PIC setup, SSI functions.

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

Regards,

Graeme

[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 

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

[Jon Loeliger]

Mike Frysinger wrote:

> i doubt it.  the only hard & fast rule is dont make Wolfgang disagreeable.
> -mike

Come now!  WD is never disagreeable!  He may disagree with you,
but I've always found him to be a rather pleasant sort of fellow!

jdl

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

[Wolfgang Denk]

Dear Jon,

In message <49244B93.3020502@freescale.com> you wrote:
> 
> Come now!  WD is never disagreeable!  He may disagree with you,
> but I've always found him to be a rather pleasant sort of fellow!

Thanks, Jon. But there are days when I'm in a bad mood and cannot see
the wood for the trees myself.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Conscious is when you are aware of something, and conscience is  when
you wish you weren't.