[U-Boot] [RFC] initcall mechanism introduction

[Stefan Roese]

On Wednesday 27 May 2009 09:52:35 Haavard Skinnemoen wrote:
> Wolfgang Denk wrote:
> > > 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.
>
> In other words, what we have right now is the worst of both worlds:
>   - There are shitloads of #ifdefs in the arch code to cope with
>     different board requirements.

ACK. Most of this code was added a long time ago. We wouldn't accept this 
board specific "hacks" (especially in lib_ppc/board.c) in the common code 
right now any more.

>   - There are huge differences between each architecture's init
>     sequence which makes it hard to write generic code elsewhere, and
>     hard to maintain each architecture since the init sequence needs to
>     be changed when new boards add new features, and there's no
>     "standard" way of doing it so the chances of getting it right to
>     begin with are very slim.
>
> Also, the chances of getting this mess cleaned up is very slim since
> you need to touch all architectures in order to change something.

Yes, I noticed this while moving the malloc initialisation to an earlier 
stage. It would be really a great improvement if we could consolidate those 
lib_arch/board.c implementations somehow.

> IMO, introducing a common init sequence for all architectures would be
> an important step on the way to make this code somewhat maintainable,
> no matter how messy the initial result ends up being. Or perhaps a
> better first step would be to clean up the ppc code since it's what new
> architectures tend to copy, and it's just such an insane mess right now.

ACK. Even though I don't have a clue right now how this could be accomplished 
in practise without breaking some of the (old) board ports.

Nevertheless I think that Jean-Christophe's inicall approach is a good idea 
which could/should be used here.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================