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? :-)
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.
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.
Best regards,
Wolfgang Denk