[U-Boot] [RFC] initcall mechanism introduction

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:54 Tue 26 May     , 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...
> 
> > In what practical case would one arch want to run component X before
> > component Y, but another want to run component Y before component X?  If
> 
> Boards are different... see for example "lib_ppc/board.c" - on some
> boards (BAB7xx and CPC45) we must initialize PCI early, while on some
> others we cannot initialize it that early.
so it's not really a problem as you can create for thoze two specific boards an
early init easly

and just for the understanding why does they need it?
> 
> > 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.
not really the initcall can be easly update via early init or if really need
by updating the linker script. Which I think will the last think to do.
> 
> > > The Linux way of doing initcalls is useless for U-Boot, as it addres-
> > > ses a completely different problem  and  is  based  on  a  completely
> > > different memory management model.
> > 
> > Initcalls are not the same thing as init code/data (other than the
> > coincidence that in Linux, they would typically reside in such sections). 
> > 
> > This has nothing to do with memory management.
> 
> But saving memory was one of j24's arguments?
It's true but the binary size (u-boot.bin) not the memory management

Best Regards,
J.