Hi Graeme,
On Wed, Aug 24, 2011 at 4:00 PM, Graeme Russ graeme.russ@gmail.com wrote:
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
No, and fair enough too.
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
Yes indeed.
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
Ick. The more I read of this thread the more I like your original implementation. It really doesn't seem that hard to see the order of initcalls either from System.map or objdump | grep or similar. Write a nice long Python script if you like! Your implementation allows tracing of initcalls as they are made which is a big win.
Early init cannot necessarily printf() but I don't see why initcalls must solve a problem which exists currently anyway (I have been thinking about buffering pre-console pre-reloc output and printing it later - it's not that hard, just a bit ugly).
Yes moving to a dependency-based init sounds lovely, but this is U-Boot not Upstart. We do need to keep things reasonably simple - at least with your scheme we can tell at link time what the order will be. The other thing is that init ordering is often not critical bar a few early routines, and most of these will be fixed by the order selected in the arch/xxx/lib/board.c code. Board maintainers would likely only have a few ranges within which to add their init, and strongly discouraged from inserting an init function into the middle of an existing stable sequence in that file.
I do tend to agree that merging the board.c code is a bigger win, but this might be a nice vehicle for doing it, since one could imagine an incremental approach with a CONFIG_NEW_INIT option which can be turned on/off for each board. As problems with each architecture (then each board) are ironed out, the option will turned on in the board config file.
Regards, Simon
Regards,
Graeme
PS: Regarding the late night work, kids, wives, etc. I am reminded of that 'quote' from Dr Johnson about his work with his 'U-Boot':
...that has taken eighteen hours of every day for the last ten years. My mother died; I hardly noticed. My father cut off his head and fried it in garlic in the hope of attracting my attention; I scarcely looked up from my work.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot