On Tue, Feb 3, 2009 at 2:36 AM, Stefan Reinauer stepan@coresystems.de wrote:
With a weak symbol, execution still has to be conditional:
if (function_to_call) function_to_call(params); else printk_debug("No function_to_call for this mainboard");
You're right, I did not realize this: [rminnich@192 tmp]$ cat weak2.c extern unsigned long __attribute__((weak)) strong(void); main(){strong();} [rminnich@192 tmp]$ cc weak2.c [rminnich@192 tmp]$ ./a.out Segmentation fault [rminnich@192 tmp]$
I've used weak symbols for a long time but only as a way to easily allow code to override "default" functions. This is not a usage that would have crossed my mind. :-)
Weak symbols can be frustrating when you're using code management tools like kscope or eclipse. You've to two symbols defined in the source code base -- which do you use? (yes, I know we can tell people 'just ignore the weak one' but the code analysis tools are not always that smart).
Wait. That problem is completely unrelated to weak symbols, and we will continue to have it, with weak symbols or without. Even more if we continue without weak symbols.
The reason for that is, we call functions the same. 10 mainboards have write_pirq_routing_table() ... all mainboards have "main" or "amd64_main".
Ah, I can not get anyone to try make kscope eh? :-)
because if you make kscope in v3, and you look for write_pirq_routing_table, you only see the one copy for the mainboard you are using. I'll be doing the same for eclipse. It's a simple trick: I use the makefile SOURCES variable to create the kscope project file. I did this in part because I want to easily fine the version of a function for the mainboard I am working on.
But now that I understand your point about weak symbols I guess we're ok. I still would like, long term, to put this kind of thing into the device operations as a phase 7.
Anyway, thanks for clearing me up on this question.
ron