* 2.6: Problem multiple bool/tristate prompts
@ 2003-08-07 23:59 Adrian Bunk
2003-08-08 10:03 ` Roman Zippel
0 siblings, 1 reply; 5+ messages in thread
From: Adrian Bunk @ 2003-08-07 23:59 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
Hi Roman,
I observed a problem with the following Kconfig snippet I tried to add
to 2.6.0-test2-mm5:
config BLK_DEV_PS2
tristate "PS/2 ESDI hard disk support" if BROKEN_MODULAR
bool "PS/2 ESDI hard disk support" if !BROKEN_MODULAR
Every "make *config" gives the warning
drivers/block/Kconfig:45: prompt redefined
drivers/block/Kconfig:45:warning: type of 'BLK_DEV_PS2' redefined from
'tristate' to 'boolean'
and the symbol is handled as tristate although BROKEN_MODULAR isn't
defined.
cu
Adrian
--
"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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: 2.6: Problem multiple bool/tristate prompts
2003-08-07 23:59 2.6: Problem multiple bool/tristate prompts Adrian Bunk
@ 2003-08-08 10:03 ` Roman Zippel
2003-08-08 10:37 ` Adrian Bunk
0 siblings, 1 reply; 5+ messages in thread
From: Roman Zippel @ 2003-08-08 10:03 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
Hi,
On Fri, 8 Aug 2003, Adrian Bunk wrote:
> config BLK_DEV_PS2
> tristate "PS/2 ESDI hard disk support" if BROKEN_MODULAR
> bool "PS/2 ESDI hard disk support" if !BROKEN_MODULAR
>
>
> Every "make *config" gives the warning
>
> drivers/block/Kconfig:45: prompt redefined
> drivers/block/Kconfig:45:warning: type of 'BLK_DEV_PS2' redefined from
> 'tristate' to 'boolean'
>
> and the symbol is handled as tristate although BROKEN_MODULAR isn't
> defined.
A symbol can have only a single type and the warning is a bit misleading,
the new type definition is simply ignored.
I'm not sure what you're trying makes really sense, but you have to use a
separate symbol:
config BLK_DEV_PS2_B
bool "PS/2 ESDI hard disk support" if !BROKEN_MODULAR
config BLK_DEV_PS2
tristate "PS/2 ESDI hard disk support" if BROKEN_MODULAR
default BLK_DEV_PS2_B
bye, Roman
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6: Problem multiple bool/tristate prompts
2003-08-08 10:03 ` Roman Zippel
@ 2003-08-08 10:37 ` Adrian Bunk
2003-08-08 13:26 ` Roman Zippel
0 siblings, 1 reply; 5+ messages in thread
From: Adrian Bunk @ 2003-08-08 10:37 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel
On Fri, Aug 08, 2003 at 12:03:45PM +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 8 Aug 2003, Adrian Bunk wrote:
>
> > config BLK_DEV_PS2
> > tristate "PS/2 ESDI hard disk support" if BROKEN_MODULAR
> > bool "PS/2 ESDI hard disk support" if !BROKEN_MODULAR
> >
> >
> > Every "make *config" gives the warning
> >
> > drivers/block/Kconfig:45: prompt redefined
> > drivers/block/Kconfig:45:warning: type of 'BLK_DEV_PS2' redefined from
> > 'tristate' to 'boolean'
> >
> > and the symbol is handled as tristate although BROKEN_MODULAR isn't
> > defined.
>
> A symbol can have only a single type and the warning is a bit misleading,
> the new type definition is simply ignored.
> I'm not sure what you're trying makes really sense, but you have to use a
I made a patch that lets all broken drivers depend on an (undefined)
BROKEN symbol and all drivers that don't compile on SMP on a
BROKEN_ON_SMP symbol that is only defined if !SMP.
This (undefined) BROKEN_MODULAR was an attempt to express that a driver
compiles only statically.
> separate symbol:
>
> config BLK_DEV_PS2_B
> bool "PS/2 ESDI hard disk support" if !BROKEN_MODULAR
>
> config BLK_DEV_PS2
> tristate "PS/2 ESDI hard disk support" if BROKEN_MODULAR
> default BLK_DEV_PS2_B
It's too complicated to be actually useful, but it seems I'd then need a
config BLK_DEV_PS2_TRISTATE
tristate "PS/2 ESDI hard disk support"
depends on BROKEN_MODULAR
default y if BLK_DEV_PS2=y
default m if BLK_DEV_PS2=m
config BLK_DEV_PS2_BOOL
bool "PS/2 ESDI hard disk support"
depends on !BROKEN_MODULAR
default y if BLK_DEV_PS2=y
config BLK_DEV_PS2
default y if BLK_DEV_PS2_TRISTATE=y || BLK_DEV_PS2_BOOL
default m if BLK_DEV_PS2_TRISTATE=m
Alternatively it might work with BLK_DEV_PS2_TRISTATE and
BLK_DEV_PS2_BOOL using select.
My problem isn't that important to satisfy such a complicated construct,
I can accept that there's no easy way to express this and live without
it.
> bye, Roman
cu
Adrian
--
"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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: 2.6: Problem multiple bool/tristate prompts
2003-08-08 10:37 ` Adrian Bunk
@ 2003-08-08 13:26 ` Roman Zippel
0 siblings, 0 replies; 5+ messages in thread
From: Roman Zippel @ 2003-08-08 13:26 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
Hi,
On Fri, 8 Aug 2003, Adrian Bunk wrote:
> My problem isn't that important to satisfy such a complicated construct,
> I can accept that there's no easy way to express this and live without
> it.
Dynamically changing the symbol type isn't possible and usally not needed,
if the driver can't be compiled as module, it has to use 'bool'. I'm
planning to add tags (e.g. for EXPERIMENTAL), maybe in this context it
will be easier, to better classify the brokenness of a driver, but this
will definitively not happen for 2.6.
bye, Roman
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6: Problem multiple bool/tristate prompts
@ 2003-08-08 14:09 John Bradford
0 siblings, 0 replies; 5+ messages in thread
From: John Bradford @ 2003-08-08 14:09 UTC (permalink / raw)
To: bunk, zippel; +Cc: linux-kernel
> > My problem isn't that important to satisfy such a complicated construct,
> > I can accept that there's no easy way to express this and live without
> > it.
>
> Dynamically changing the symbol type isn't possible and usally not needed,
> if the driver can't be compiled as module, it has to use 'bool'. I'm
> planning to add tags (e.g. for EXPERIMENTAL), maybe in this context it
> will be easier, to better classify the brokenness of a driver, but this
> will definitively not happen for 2.6.
Couldn't each config option simply have a flags byte, thus:
00000000
||||||||
|||||||\ Not applicable to servers
||||||\- Not applicable to desktops
|||||\-- Not applicable to embedded systems
||||\--- Not extensively tested by developers
|||\---- Not extensively tested by end users
||\----- Obsolete
|\------ Appears to compile, but known to be broken in a subtle way
\------- Does not copmile
Then we could just have a menu with:
[X] Exclude options not applicable to servers
[X] Exclude options not applicable to desktops
[X] Exclude options not applicable to embedded systems
[X] Exclude options not extensively tested by developers
[X] Exclude options not extensively tested by endusers *
[X] Exclude options marked as obsolete
[X] Exclude options which compile, but are actually broken
[X] Exclude non-compiling options
* I.E. what is currently CONFIG_EXPERIMENTAL
The flags byte could be optional, with a default value of 0.
Seems more practical than using config options, and it would make some
interesting statistics easily available.
John.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-08-08 14:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-07 23:59 2.6: Problem multiple bool/tristate prompts Adrian Bunk
2003-08-08 10:03 ` Roman Zippel
2003-08-08 10:37 ` Adrian Bunk
2003-08-08 13:26 ` Roman Zippel
2003-08-08 14:09 John Bradford
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).