Skip to contentSkip to conversation

New kconfig: Please add define_*

DISCUSSION Adrian Bunk 3 participants 5 messages Nov 21, 2002 – Nov 23, 2002

lore
Share & tools
lore
#0 lore raw

Hi Roman,

one thing that easily leads to errors is that the difference between e.g. bool and define_bool is less obvious than before (it's no longer explicitely stated). If there's no string behind the bool and no "prompt" line it's now treated as define_bool. I've already found two places in sound/oss/Kconfig where this was missing accidentially. Could you add explicite define_* back to the config language and let the program quit with an error if there's e.g. a define_bool with a string or prompt line or a bool without a string or prompt line?

I know this requiress a conversion of several Kconfig files but considering that this might prevent some confusion in the future I think it's worth it.

TIA
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 Seed
#1 lore raw

Hi,

Quoted 8 lines · Adrian Bunk

one thing that easily leads to errors is that the difference between e.g. bool and define_bool is less obvious than before (it's no longer explicitely stated). If there's no string behind the bool and no "prompt" line it's now treated as define_bool. I've already found two places in sound/oss/Kconfig where this was missing accidentially. Could you add explicite define_* back to the config language and let the program quit with an error if there's e.g. a define_bool with a string or prompt line or a bool without a string or prompt line?

It was not missing accidentially, these symbols were defined with define_bool before.
I'll think about the define_* syntax, but I will not make the other syntax illegal. The current 'bool "prompt"' is already a shortcut for the more common requirement:

config FOO

	bool
	prompt '...'

Also note that the role of the default has changed, a default cannot override a prompt anymore (it only provides a default value to the prompt). The define_* syntax might imply that this is possible, but it won't.

bye, Roman

#2 lore raw
Quoted 4 lines · Roman Zippel

Also note that the role of the default has changed, a default cannot override a prompt anymore (it only provides a default value to the prompt). The define_* syntax might imply that this is possible, but it won't.

I'd like to be able to override a prompt.

The reason is that in general it's nice for the arch-specific Kconfig file to include various other Kconfig files (using `source'), but sometimes an option that usually makes sense as user-definable -- and thus has a prompt -- _doesn't_ make sense on that particular architecture.

Currently it seems as if the arch-specific Kconfig can do several things in this case:

(1) Inline the more general Kconfig into the arch-specific Kconfig (with the offending option removed, and omit the `source'). This is undesirable for all the usual reasons (code duplication causes bit-rot etc).

(2) Document somewhere that users shouldn't ever set option FOO, even though it asks the question. This is confusing for users.

(3) Add a dependency on ARCH_BLAH or something to the definition of FOO. This is probably the cleanest solution, but tends to result in arch-specific knowledge being littered all over the place (though this is already a general problem with the config system).

It would nice if I could just say in my arch-specific Kconfig:

option FOO
bool
set n

which would force FOO to `n' regardless of any later declarations.

-Miles

Signature · 1 line
`Life is a boundless sea of bitterness'
#3 lore raw

Hi,

Quoted 7 lines

I'd like to be able to override a prompt.

The reason is that in general it's nice for the arch-specific Kconfig file to include various other Kconfig files (using `source'), but sometimes an option that usually makes sense as user-definable -- and thus has a prompt -- _doesn't_ make sense on that particular architecture.

Do you have a specific example? What I've seen so far (especially cris was full of it), was more used to override the user (and only worked with 'make oldconfig' anyway). Only because most users want to include specific drivers, doesn't mean all users have to include these drivers. I'm a bit afraid such a feature would be easily misused.
It sounds more like you want an autoconf, which generates a machine specific config. E.g. ppc already delivers several config files for different machines, which are selected with 'make <mach>_config'. Going into this direction sounds like a better idea.

bye, Roman

#4 lore raw
In reply to Roman Zippel
Quoted 1 line · Roman Zippel

Hi,

Hi Roman,

Quoted 11 lines · Adrian Bunk
Quoted 9 lines

one thing that easily leads to errors is that the difference between e.g. bool and define_bool is less obvious than before (it's no longer explicitely stated). If there's no string behind the bool and no "prompt" line it's now treated as define_bool. I've already found two places in sound/oss/Kconfig where this was missing accidentially. Could you add explicite define_* back to the config language and let the program quit with an error if there's e.g. a define_bool with a string or prompt line or a bool without a string or prompt line?

Quoted 3 lines

It was not missing accidentially, these symbols were defined with define_bool before.
...

/me checks 2.5.44

You are right, it was a define_bool before. I thought "this must be a bug" and I didn't even read the comments above the options...

A define_bool might make it more obvious for dumb people like me that it is really intended the way it is. ;-)

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 Seed