Richard Smith wrote:
On 9/15/06, Stefan Reinauer stepan@coresystems.de wrote:
- Richard Smith smithbone@gmail.com [060915 18:03]:
One line of text _cannot_ accurately describe these options.
YES! We need Linux Kconfig.
I remember many moons ago we talked about using Kconfig. And we chose not to. IIRC t the time Kconfig was seen as not being able to deal with our hardware tree structures. But that was a long time ago.
The tricky part for me is still this. If I have four instances of X driver, there's no way I know of in kconfig to set different params for each instance. In kconfig, you say "I have an X", but you can't say, "this is another instance of X, but this time, turn OFF this feature". For example, take this: config 8139TOO_PIO bool "Use PIO instead of MMIO" default y depends on 8139TOO
You can't say "use PIO for instance 1 and don't use it for instance 2". That's not doable in Konfig. There's only one 8139TOO_PIO, and it applies to ALL instances of the 8139. But in our config, we can set that option differently for each and every part. And, we have to be able to do this.
Here's the subtlety. In our config system, when you enter and exit blocks, a new local symbol table is pushed and popped for that block. Option variables not yet in use can be used in that block. The symbols are hierarchical. That's why I can, for example, have lots of these: chip northbridge/amd/amdk8 with totally different settings for each one.
Any mod to the config system -- or new config system -- needs to take this into account. Settings for instances of a given part are not the same for all instances of that part -- they can't be, at the bios level. I don't think Linux Kconfig can accomodate that, but maybe it can. The Kconfig 'all variables global' rule seems to indicate it can't.
Again, in linux kconfig, all variables are global. In our config, they are not. (hence 'uses', which I well understand we all dislike).
It's funny to hear us arguing *for* global variables :-),but we are :-)
thanks ron