2.5 kconfig doesn't handle "&& m" correctly
Hi Roman,
while looking for the reason for a compile error in 2.5.48 I noticed the following that seems to be a bug in the new kconfig:
The following is with a .config that was generated using "make oldconfig":
<-- snip -->
$ grep SOUND_WAVEFRONT .config CONFIG_SOUND_WAVEFRONT=y $
<-- snip -->
sound/oss/Kconfig contains the following:
<-- snip -->
...
config SOUND_WAVEFRONT
tristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards" depends on SOUND_OSS && m
...
<-- snip -->
It seems the "&& m" (a common way to ensure that something can only be built modular) isn't handled correctly.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedHi,
Quoted 10 lines · Adrian Bunk
config
SOUND_WAVEFRONTtristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards" depends on SOUND_OSS && m...
<-- snip -->
It seems the "&& m" (a common way to ensure that something can only be built modular) isn't handled correctly.
Did you disable modules? When modules are disabled tristate symbols are treated like booleans, that means they are visible if the dependencies are different than 'n'. For this it should be possible to automatically add '&& MODULES' if the parser sees a 'm'. I'll have to check this out.
bye, Roman
Quoted 1 line · Roman Zippel
Hi,
Hi Roman,
Quoted 7 lines · Adrian Bunk
Quoted 6 lines
config
SOUND_WAVEFRONTtristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards" depends on SOUND_OSS && m...
Quoted 7 lines
Quoted 5 lines
<-- snip -->
It seems the "&& m" (a common way to ensure that something can only be built modular) isn't handled correctly.
Did you disable modules? When modules are disabled tristate symbols are
yes, this was with a .config without modules support.
Quoted 3 lines
treated like booleans, that means they are visible if the dependencies are different than 'n'. For this it should be possible to automatically add '&& MODULES' if the parser sees a 'm'. I'll have to check this out.
My first thought is that this sounds like a workaround. Is there a good reason not to restore the semantics of the old kconfig that interpreted dependencies as a restriction of the input range?
Quoted 1 line
bye, Roman
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedHi,
Quoted 7 lines · Adrian Bunk
Quoted 3 lines
treated like booleans, that means they are visible if the dependencies are different than 'n'. For this it should be possible to automatically add '&& MODULES' if the parser sees a 'm'. I'll have to check this out.
My first thought is that this sounds like a workaround. Is there a good reason not to restore the semantics of the old kconfig that interpreted dependencies as a restriction of the input range?
It still does mostly, that's one case I missed. The old config had more than one semantic regarding visible input range (the shell 'if' semantic and the dep_* dependencies, which differed again between the commands), kconfig has only one. So it's not matter of restoring semantics, but translating them correctly. In general a symbol is now visibile is if the dependencies are !='n', "restoring" would mean to change this into ='y' only for tristate symbols when MODULES='n', this would be an even larger hack. Translating 'm' into 'm && MODULES' is the cleaner solution, as it doesn't change the base kconfig logic.
bye, Roman