In message 200211061403.16141.h.schurig@mn-logistik.de you wrote:
But the bootdelay is NOT an internal definition. And many other CFG_ aren't internal, too. Okay, I can see that CFG_CMD_ are internal definitions and that only CONFIG_COMMANDS is user definiable. However, lkc will not easily handle this.
Ummm... what about extending lkc then?
This is because LKC can
- only handle config vars that start with CONFIG_
- has only types like int, string, bool, but not bitmask
This is a serious rrestriction.
and CONFIG_COMMANDS is a bitmask. Of course one could put
define COMMAND int "Which commands to allow" default <some value> help This is really a bitmask. Add the following values to get your result: 1 for bdinfo 2 for loads 4 for loadb
but that would be a step backwords. I'd rather have it like this
Such an implementation would be just unacceptable. Also, are you sure that it performs a 64 bit addition?
menu "Command selection"
define CMD_BDI bool "bdinfo command (board info) default y
define CMD_LOADS bool "loads command (load srec file) default n
define CMD_LOADB bool "loadb command (load binary file) default n
endmenu
and so on.
Does not work. There are some board which want "everything but features A, B and C".
If we want to use lkc for this, we have to transfer files like cmd_elf.c from
#if (CONFIG_COMMANDS & CFG_CMD_ELF)
into
#ifdef CONFIG_CMD_ELF
Therefore, I assume that lkc is intrusive. Either change the whole u-boot or nothing at all. As in the linux kernel: it's not changed totally,
I don't object againdt lkc in general. In fact I'd like to see a way for easier configuration. But then, when you check just 20 randomly chosen board config files, you will find such a wide range of private extensions, which are strictly "local" (i. e. of interest only for that specific board), that I think it would be extremely difficult to maintain this under lkc. And combining a lkc created config file with a second, board private config file, seems contraproductivee to me. But adding all these things to lkc will cause a level of complexity for the resulting lkc input that will be probably much harder to maintain than the current header files.
To make the long story short: I don't see much chance for real improvement.
Also there are two levels of things, requiring different level of expertise: simple default settings like console baudrate, which don't require much intelligence, and hardware specific stull like memory timings or register initial values which require an in-depth understanding of the hardware.
It is probably not a good idea to mix both in an interface which might create the issusion that Johny Luser can change everything.
Best regards,
Wolfgang Denk