[U-Boot] Code style questions (weak functions, cpu/ v's lib_arch/)
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
On Tuesday 18 November 2008 17:35:04 Graeme Russ wrote:
- 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.
- 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
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
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
participants (4)
-
Graeme Russ -
Jon Loeliger -
Mike Frysinger -
Wolfgang Denk