Dear Simon,
In message CAPnjgZ38HPmOf07CMYssa1Q167sRjzDpbBUbCVMaoGdRoWESog@mail.gmail.com you wrote:
Thanks for looking at this so closely - it's just an RFC at this stage, but I think it has promise.
Agreed.
I think config_* is not a good name to use here - it has never been a reserved prefix so far, so it is IMO a bad idea to turn it into one now . We already have quite a number such variable names in the code all over the place (not sure I caught them all):
...
These are variables, so won't conflict with the function macros used by this patch. But maybe we should try for something like cfg_...()?
You are wrong. This includes a number of functions, and macros, too, for example:
void config_sdram(const struct emif_regs *regs); void config_ddr_phy(const struct emif_regs *regs); void config_cmd_ctrl(const struct cmd_control *cmd); void config_ddr_data(int data_macrono, ...) void config_io_ctrl(unsigned long val); void config_ddr(unsigned int pll, unsigned int ioctrl, void config_data_eye_leveling_samples(u32 emif_base); static int config_pll_clk(enum pll_clocks index, ...) static int config_core_clk(u32 ref, u32 freq) # define config_fifo(dir, idx, addr)
And cfg_ is not much better:
#define cfg_read(val, addr, type, op) #define cfg_write(val, addr, type, op) u16 cfg_type = 0; unsigned cfg_val; u32 *cfg_reg; uint cfg_addr; uint cfg_data; ...
I did for the 'sed' step - it was a 2-3 seconds to regenerate the header files.
Full reconfig/recompile goes from about about 30s to 34s. Incremental build doesn't change noticeably.
I'm mostly concerned about build time for the autobuilder, which does full config / build cycles for all boards. Here more than 10% increase hurt...
I also tried recompiling both the mainline U-Boot's main.c 100 times, and then this one. I could not see any time difference, which is a little surprising. Maybe the C compiler's DCE is pretty early in the the process?
This is a surprising result, indeed.
if (config_autoboot_delay_str() && delaykey[0].str == NULL)delaykey[0].str = config_autoboot_delay_str();Hm.... constructs like these make me think about side effects. As is, your implementation does not pretect against any. This may be dangerous - you are evaluating the macro multiple times now, while before it was only a defined() test, folowed by a single evaluation.
You did not comment on this remark. I think it is something to keep in mind!
And to be honest - I find the old code easier to read.
:-)
But if you have time, please take a look at the sed scripts and the Makefile.
Sorry, but I can't find the audacity to bend my mind around these currently ;-)
But you might have a look at "tools/scripts/define2mk.sed" and either use this as is, or base your code on this. I would find it good to use the same code for the same (or so very similar) purposes.
The background here is that I have been wondering about this for a while, but have never really come up with a good way (in the absence of a unified Kconfig) of getting a complete list of CONFIG variables.
Does not the already existing "include/autoconf.mk" contain this information? In any case, please check "tools/scripts/define2mk.sed"
There was a mailing list post about this a few weeks ago. But then David Hendrix complained about main.c which spurred me into action, and I thought maybe we could just live with a brute force 'find/grep/sed' approach for now, rather than trying to be too clever. That's what I have done here.
Understood, and appreciated.
I will come back to this when I have time - will be a week or two.
Thanks.
Best regards,
Wolfgang Denk