2.6: Problem multiple bool/tristate prompts

2.6: Problem multiple bool/tristate prompts

[Adrian Bunk]

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

Re: 2.6: Problem multiple bool/tristate prompts

[Roman Zippel]

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

Re: 2.6: Problem multiple bool/tristate prompts

[Adrian Bunk]

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

Re: 2.6: Problem multiple bool/tristate prompts

[Roman Zippel]

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

Re: 2.6: Problem multiple bool/tristate prompts

[John Bradford]

> > 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.