Hi Wolfgang
On Wed, Aug 24, 2011 at 11:58 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Wolfgang,
On 24/08/11 23:24, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 4E54F501.6050706@gmail.com you wrote:
[snip]
Hmmm, now we're talking ;) Let me ramble aimlessly for a second...
I can see this heading towards an auto-generated init-sequence.c file with an init array specifically crafted for the build target. That would have less linker functionality dependencies than initcall...
So if we define a file, say 'init.txt' which lists the init dependencies and we drill-down and pre-process this to generate /common/init-sequence.c which has the array of function pointers (and optionally the function name strings for debug output...)
Hmmm, it _sounds_ messy on the surface, but it is a pre-compile step so what you get code-wise for the final build is exactly what you want - A clean array that is 'right there'
So we might have in init.txt for a board:
INIT_STEP_TIMER(board_foo_timer_init) DEPENDS_ON(INIT_STEP_ARM_TIMER)
and in arch/arm/Soc/init.txt
INIT_STEP_ARM_TIMER(arm_timer_init) DEPENDS(INIT_STEP_SDRAM) DEPENDS(INIT_STEP_GPIO)
Can't say I like it much...could be xml, but still very clunky
Maybe there is something to be gleaned...
Dunno - thoughts?
Midnight is not the best time to come up with ideas ;) - Way to much convaluted pre-processing, non of it in native C code (or even pre- processor) - Yetch! All to complicated for a very simple goal:
- Allow any arch/Soc/board to seamlessly inject an init function without needing to modify any other files other than its own.
In essance, I see three 'big' problems with the initcall implementation:
1. Do all linkers used to compile latest mailline U-Boot support SORT_BY_NAME()? If not, game over 2. There is no definative init sequence list in the code (a la the current init function array) 3. Managing the init call sequence
There is nothing I can do about #1 as mentioned before
For #2, if we had a post-build step which generated the init sequence into a text file for reference would that help? If I name the initcall sections something like .initfunc.1000.init_cpu_f then it will be pretty trivial to post-process u-boot.map
As for #3 - What about INIT_AFTER (and maybe INIT_BEFORE) macros so you may have in init.h
#define INIT_START 1000
and in /arch/.../cpu.c:
INIT_AFTER(INIT_START, init_cpu_f) int init_cpu_f(void) { ... }
The only problem I have with that is that you cannot define a new macro in a macro. I would love to do:
INIT_AFTER(INIT_START, init_cpu_f, INIT_CPU_F)
which would then define INIT_CPU_F so you could then:
INIT_AFTER(INIT_CPU_F, init_timers_f, INIT_TIMERS_F)
but I cannot figure out how that would work
Regards,
Graeme