Dear Graeme Russ,
In message CALButCLX42Q=u33gCOKA+LoZZ+RZO1Y-SXNhE8MK66DfrU9YPA@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