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