[LinuxBIOS] changes in decompress coming.

Ronald G Minnich rminnich at lanl.gov
Fri Sep 15 18:55:21 CEST 2006

Richard Smith wrote:
> On 9/15/06, Stefan Reinauer <stepan at coresystems.de> wrote:
>> * Richard Smith <smithbone at 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 :-)


More information about the coreboot mailing list