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

[Graeme Russ]

Hi Wolfgang,

On Wed, Aug 24, 2011 at 4:48 PM, Wolfgang Denk <wd at denx.de> wrote:
> 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.

Well if the use of grep irks you so, I dare you to rm grep ;)

>> > 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 }

Ah, so turn the current array into a two element array containing a
function pointer and string pointer. I guess that would work, but that will
totally change the symantics of the static variable between debug and non
debug builds - Not an optimal scenario in my mind

>> 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.

I would hardly call 'grep' an extra tool - How many programmers do you
know that have never used grep?

>> > 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.

And by defining #DEBUG I can have a parallel list of function names so when
the loop picks up the next funtion pointer, it picks up the name as well
ready to examine before stepping in - OK, not ideal, but still, I think
the flexibility to seamlessly inject init functions at the board level
outweighs this

>> 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.

Technically we have the same issue with weak functions - Just because you
have code that overrides them, does not mean that code gets compiled in.

The initcall solution introduces no additional 'issues' that we are not
already dealing with on a day-to-day basis.

> 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.

Sorry, I don't have a crystal ball

Regards,

Graeme