Messing with Kconfig.

Messing with Kconfig.

[Rob Landley]

So I'm looking at menuconfig and contemplating rearranging the heck out of it 
to slather some calamine lotion on one of my longstanding personal itches.  
(You may have seen a couple trivial patches float by.)   I thought it would 
be polite to ask about a couple of things before trying anything major:

1) There are no actual options at the top level, and I'm wondering if that's 
policy or coincidence.  For example, CONFIG_EXPERIMENTAL lives by itself in a 
wrapper menu that's pretty darn specifically tailored to it, and is unlikely 
to grow too many more options.  Would taking it out of the wrapper menu be a 
bad thing?

2) There's at least two different menu types.  The standard top-level menus 
are just "descend into this" (the "menu" type), often with a guard item at 
the top of the menu you descend into that deactivates and hides everything in 
it.  But a couple (like CONFIG_EMBEDDED, under general setup) are type 
"menuconfig", where you have to select the menu in order to be able to 
descend into it.  These two are basically functionally equivalent,but provide 
have two different user interface styles.  Which is preferred?  (The 
menuconfig type is more straightforward and more compact, but also slightly 
easier to miss the need to descend into something and configure stuff.  Is 
there some kind of subtle policy here, using one to indicate a pure guard 
item with no associated functionality (which only affects the configurator 
and not generated code), and the other to indicate associated generated code 
is attached?  Or what?)

4) Some menu guards don't actually disable everything in their menu when you 
switch 'em off.  The CONFIG_INPUT is one example, CONFIG_VIDEO_DEV is 
another.

5) Is the indentation level supposed to mean something?  Look at PCI IDE 
chipset support, for example.  Disable it and the indented menu items under 
it disappear, along with a dozen or so menu items underneath it that aren't 
indented.  Am I missing a subtle policy issue here?  (It makes cases like 
"does USB Gadet support need USB Support, cause it doesn't go away when you 
disable it" harder to figure out...)

6) In test-2, if you do a make distclean (zapping your .config) and also rip
the config out  of /boot, and then do a make menuconfig, you get the
following:

boolean symbol BINFMT_ZFLAT tested for 'm'? test forced to 'n'
#
# using defaults found in arch/i386/defconfig
#
arch/i386/defconfig:68: trying to assign nonexistent symbol X86_SSE2
arch/i386/defconfig:182: trying to assign nonexistent symbol PNP_CARD
arch/i386/defconfig:324: trying to assign nonexistent symbol SCSI_EATA_DMA
arch/i386/defconfig:336: trying to assign nonexistent symbol SCSI_NCR53C7xx
arch/i386/defconfig:338: trying to assign nonexistent symbol SCSI_NCR53C8XX
arch/i386/defconfig:361: trying to assign nonexistent symbol SCSI_PCMCIA
arch/i386/defconfig:395: trying to assign nonexistent symbol FILTER
arch/i386/defconfig:544: trying to assign nonexistent symbol NET_PCMCIA_RADIO
arch/i386/defconfig:663: trying to assign nonexistent symbol INTEL_RNG
arch/i386/defconfig:664: trying to assign nonexistent symbol AMD_RNG
arch/i386/defconfig:678: trying to assign nonexistent symbol AGP3

This is a bad thing, yes?

Rob

Re: Messing with Kconfig.

[Roman Zippel]

Hi,

On Fri, 1 Aug 2003, Rob Landley wrote:

> 1) There are no actual options at the top level, and I'm wondering if that's 
> policy or coincidence.  For example, CONFIG_EXPERIMENTAL lives by itself in a 
> wrapper menu that's pretty darn specifically tailored to it, and is unlikely 
> to grow too many more options.  Would taking it out of the wrapper menu be a 
> bad thing?

Kconfig now supports config options at the top level, but changing the 
position of CONFIG_EXPERIMENTAL at this point is probably a bad idea.

> 2) There's at least two different menu types.  The standard top-level menus 
> are just "descend into this" (the "menu" type), often with a guard item at 
> the top of the menu you descend into that deactivates and hides everything in 
> it.  But a couple (like CONFIG_EMBEDDED, under general setup) are type 
> "menuconfig", where you have to select the menu in order to be able to 
> descend into it.  These two are basically functionally equivalent,but provide 
> have two different user interface styles.  Which is preferred?

menuconfig is meant for generic options, like CONFIG_IDE or CONFIG_SCSI, 
so that you can easily see whether they are enabled or not.

> 4) Some menu guards don't actually disable everything in their menu when you 
> switch 'em off.  The CONFIG_INPUT is one example, CONFIG_VIDEO_DEV is 
> another.

This should be fixed.

> 5) Is the indentation level supposed to mean something?  Look at PCI IDE 
> chipset support, for example.  Disable it and the indented menu items under 
> it disappear, along with a dozen or so menu items underneath it that aren't 
> indented.  Am I missing a subtle policy issue here?  (It makes cases like 
> "does USB Gadet support need USB Support, cause it doesn't go away when you 
> disable it" harder to figure out...)

Yes, it's supposed to help the user, how options are related. This needs 
some manual fixing. If you want to start somewhere, try to fix these 
first. It usually requires only moving an option around or adding another 
dependency. xconfig is extremly useful here, enable "show all options" and 
you can easily see which option breaks the indentation and the debug info 
tells you where to find this option.
Please don't do any major reorganization, this is not what we need right 
now.

> 6) In test-2, if you do a make distclean (zapping your .config) and also rip
> the config out  of /boot, and then do a make menuconfig, you get the
> following:

arch/i386/defconfig needs to be updated from time to time.

bye, Roman

Re: Messing with Kconfig.

[Bartlomiej Zolnierkiewicz]

On Fri, 1 Aug 2003, Rob Landley wrote:

> 5) Is the indentation level supposed to mean something?  Look at PCI IDE
> chipset support, for example.  Disable it and the indented menu items under
> it disappear, along with a dozen or so menu items underneath it that aren't
> indented.  Am I missing a subtle policy issue here?  (It makes cases like

IDE has been recently fixed, patches are at
http://home.elka.pw.edu.pl/~bzolnier/ide-Kconfig/

Just FYI to not waste time on it. :-)
--
Bartlomiej

Re: Messing with Kconfig.

[John Bradford]

> So I'm looking at menuconfig and contemplating rearranging the heck out of it

Please don't.  This comes up from time to time on the mailing list,
and massive re-arrangements are usually a Bad Thing.

John.

Re: Messing with Kconfig.

[Rob Landley]

On Friday 01 August 2003 05:01, John Bradford wrote:
> > So I'm looking at menuconfig and contemplating rearranging the heck out
> > of it
>
> Please don't.  This comes up from time to time on the mailing list,
> and massive re-arrangements are usually a Bad Thing.
>
> John.

I know a big flag day rearrangement would never be accepted.  It would have to 
be a series of small, self-contained patches that could be individually 
approved or vetoed.  (And several of them will be vetoed, this is normal.)

I know the drill.  You get there from here in quarter-inch steps...

Rob

Re: Messing with Kconfig.

[Nicolas Pitre]

On Fri, 1 Aug 2003, John Bradford wrote:

> > So I'm looking at menuconfig and contemplating rearranging the heck out of it
> 
> Please don't.  This comes up from time to time on the mailing list,
> and massive re-arrangements are usually a Bad Thing.

Of course "massive" re-arrangements all at once have always been rejected,
and we've seen obvious examples of that in the kernel build/config system
area already.

One should have learned, though, that small incremental changes can achieve
similar results and are much more acceptable to the rest of the community.


Nicolas

Re: Messing with Kconfig.

[Rob Landley]

On Friday 01 August 2003 11:27, Nicolas Pitre wrote:
> On Fri, 1 Aug 2003, John Bradford wrote:
> > > So I'm looking at menuconfig and contemplating rearranging the heck out
> > > of it
> >
> > Please don't.  This comes up from time to time on the mailing list,
> > and massive re-arrangements are usually a Bad Thing.
>
> Of course "massive" re-arrangements all at once have always been rejected,
> and we've seen obvious examples of that in the kernel build/config system
> area already.
>
> One should have learned, though, that small incremental changes can achieve
> similar results and are much more acceptable to the rest of the community.

And one has to go especially slow during -test.  And if a change doesn't get 
merged immediately, you have to maintain it until there's an opening.  And if 
somebody ever actually tells you WHY it's wrong, this is not criticism but an 
opportunity to FIX it (sometimes by dropping the change)...

> Nicolas

Rob