Dear Graeme Russ, In message <CALButCLX42Q=u33gcoka+lozz+rzo1y-sxnhe8mk66dfru9...@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: w...@denx.de If there are self-made purgatories, then we all have to live in them. -- Spock, "This Side of Paradise", stardate 3417.7 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot