Hi Wolfgang,
On 24/08/11 23:24, Wolfgang Denk wrote:
Dear Graeme Russ,
In message 4E54F501.6050706@gmail.com you wrote:
Sorry, but when reading the source code or when revioewing patches I cannot paick up any next funtion pointers, I'm stuck with reading the source code only.
Well, I guess I had a good shot at creating a 'better' init sequence - one where any board, SoC, or arch can seamlessly inject a custom init step without treading on any toes.
I must say, it was rather fun learning how to build the macros and get the linker to do the right thing and have it all work so quickly. I'll stick it in my bag of tricks for another day :)
Hey, you give up early. Are you suffering from hot weather, too? :-)
No, just young kids, new job and pregnant wife :)
Seriously, I do not think we should stop this discussion yet. I agree that a better approach to the init code would be a good thing, but at the same time I want to make sure the result will be really better, and we not by means of Beelzebub expel the demons...
I already tried to lend a helping hand by suggesting to create a list of init functions as part of the build process - OK, we still have to build the code to get this, but at last we can then see the complete and precise order for this specific configuration.
Something like how we auto generate asm-offsets.h?
Also, Detlev made some interesting remarks - he noted that basicly what we are trying to solve is a dependency issue: each init function has a list of dependencies (other init steps) that need to be run before. Instead of manually assigning initcall numbers, we could try and write down these dependencies, for example in a format that can be digested by a tool like tsort. We could then use this to auto-generate the list of init calls. This is a completely new approach, but it has the charme of making the dependencies clear.
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?
Regards,
Graeme