[lkml]   [2003]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6: Problem multiple bool/tristate prompts
> > 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:

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.038 / U:1.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site