[U-Boot] [RFC] initcall mechanism introduction

[Scott Wood]

Wolfgang Denk wrote:
> Dear Scott,
> 
> in message <20090526210046.GA4669 at b07421-ec1.am.freescale.net> you wrote:
>> IMHO, it is much better for the information on what needs to be run on
>> init to reside in the file that needs to be called, rather than copied to
>> a bunch of different arch files.
> 
> Then you might end up with another maze of #ifdef's...

Only when you have a situation like the BAB7xx/CPC45 (in which case you 
could ifdef the priority -- or just ifndef the initcall for those boards 
and handle that special case manually).  You wouldn't have ifdefs for 
just the presence of the thing that needs to be initialized, and it 
would be only in one place rather than X arch files.

>> component X is always supposed to come before component Y, that can be
>> done with different levels of initcalls, or just by arranging the
>> makefiles appropriately (with a comment warning people not to change it).
> 
> The problem is that there is no such fix order. It is board dependent.

There will be exceptions, but for many things there's just no reason for 
the board to care (such as the time at which we run relocation fixups or 
other data structure initialization for things in common/).  One 
shouldn't have to change a bunch of arch files in order to add some new 
common code that needs init.

>> This has nothing to do with memory management.
> 
> But saving memory was one of j24's arguments?

I assume he meant that the image size was smaller, due to replacing 
explicit function calls with a table-driven approach.

-Scott