[U-Boot] initcall revisited - A new idea to discuss

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCLVdsiGMpwt04+-aQPDVJ_zx9ZZkbXH+ifcSxDxaBdv3A at mail.gmail.com> you wrote:
> 
> > Can we get rid of the 'f' parameter? If we invent a prerequisite
> > called 'relocated' or something like that, to act as a barrier, then
> > maybe the order can be defined just like any other function which
> > depends on being before or after something?
> 
> Well I kind of like see that a particular init function is explicitly a
> pre- or post- relocation function. But yes, having barrier pre-requisites
> would achieve the same effect.

I like the idea of having general synchronization (or barrier)
entries, instead of pre- or post relocation, especially when
considering the case of different configurations with or without SPL
code or with externel pre-loaders or ...

> > I wonder what happens when you skip something - does it substitute for
> > any pre/post-requisites that the skipped item had? Or would that be
> > illegal?
> 
> SKIP_INIT(foo) simply removes all 'foo' init functions from the list
> _after_ the list has been created - If this breaks dependencies that's
> your problem ;). It is up to you as the 'skipper' to make sure that you
> add init functions to allow things to still work

Isn't that always the case? The functionsprovided by the user must
perform their task - the dependency checking can only test the
exitence of the function that claims to provide a specific property,
but it cannot check if it actually does so.

> With this proposal, if a board wants to entirely re-write the init
> sequence, it can add a whole bunch of SKIP_INIT(blah) and then add it's
> own INIT_FUNC(init_func, "myboard_bar"...) and nobody else will be the
> wiser as to what is going on. The problem the is if the arch adds a new
> init step, it may not be covered by the skip list by that board - tough,
> lesson learn't for being so esoteric ;)

We do something similar to the implemetnation of CONFIG_CMD_ and offer
a way not to include the default init list at all.

> > Anyway, it sounds very promising.
> 
> Yes, it's a lot better than my original proposal :)

It's fun to see this grow.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A fail-safe circuit will destroy others.                 -- Klipstein