[U-Boot] [RFC] New init sequence processing without init_sequence array

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCLX42Q=u33gCOKA+LoZZ+RZO1Y-SXNhE8MK66DfrU9YPA at mail.gmail.com> you wrote:
> 
> > But frankly: do you consider this list above _readable_?
...
> grep is your friend - All you need to to is grep for GLOBAL (actually I
> think COMMON is a better name) and the ARCH, SOC, and BOARD keywords in
> the namespace for your board and voila - You have a sorted list of the
> init sequence for you board

Yes, this is exactly what I mean.  I will need additional tools to
be able to read the code.  I cannot - for example - print a few pages
of source code and check the lines that worked, or similar.

> > It would be trivial to enable printing the names from the loop; we
> > can't do it because we don't have the needed prerequisites yet in most
> > cases.
> 
> How so? I cannot see how you could create a macro which when used in the
> static array initialiser would send the function pointers to one array and
> the string names (or pointers to) to another array.

See the example in the CPP info pages: cpp.info, Node: Concatenation:

	#define COMMAND(NAME)  { #NAME, NAME ## _command }

> How does debugging in that case work now? There is no difference between
> the two implementations - the only thing I am changing is:

Right.  So we cannot say that the initcall code is any improvment here.

> > The difference is that I have a source file for reference.
> 
> Huh? You still do in the initcall case

Agreed.  I should have written: I have a _readable_ source file that
can be parsed without additional tools.

> > With the init.h as above I have no such reference.
> 
> No reference to what? - the static array of function pointers? This is of
> little use anyway as all your debug stepping will do is pick up the next
> value from the array

But I can _see_ what the next entry will be.

> No, it becomes a clean linear list of the init sequence from which you
> can easily grep out the noise. This list will never have an init step
> defined out-of-order. If INIT_YOUR_BOARD_ETHERNET occurs after
> INIT_YOUR_ARCH_PCI in the list then you know your board initialises its
> Ehternet after the arch has initialised PCI

If I see some INIT_YOUR_ARCH_FOO in this list - how can I see if this
is actually being executed on my specific board?  This might depend on
a number of feature selections, so it is run on one board but not on
another.

Yes, you remove the #ifdef's - but here in this case this is exactly
the information that would be needed one way or another.


I bet that rather sooner than later you will end up with some toold
that parses either the ELF file or the linker map or the symbol table
to generate a readable list for the current build.  I bet a case of
beer that you will need such a tool.  We don't need it now.

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
If there are self-made purgatories, then we all have to live in them.
	-- Spock, "This Side of Paradise", stardate 3417.7