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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/