top-level config menu dependencies
Subsystems (3)
Hi,
It has been a long-time tradition that no "real tunable options" are present in the top level of the kernel config menu. I reckon this has to do with an inherent limitation of the original config subsystem.
While converting the way submenus appear in menuconfig depending on their main, parent config option, I stumbled upon certain subsystems (such as MTD or IrDA) that should clearly have an on/off switch directly in the main menu so that one doesn't have to enter the corresponding submenus to even see if they're enabled or disabled.
Since the new kernel configurator would have no problems with such a setup, I'm posting this RFC to get the general opinion on whether this should be carried on with. I'm willing to create and send in the patches.
Regards,
Signature · 1 line
Tomas Szepe <[email protected]>
Quoted 10 lines
It has been a long-time tradition that no "real tunable options" are present in the top level of the kernel config menu. I reckon this has to do with an inherent limitation of the original config subsystem.
While converting the way submenus appear in menuconfig depending on their main, parent config option, I stumbled upon certain subsystems (such as MTD or IrDA) that should clearly have an on/off switch directly in the main menu so that one doesn't have to enter the corresponding submenus to even see if they're enabled or disabled.
Quoted 4 lines
Since the new kernel configurator would have no problems with such a setup, I'm posting this RFC to get the general opinion on whether this should be carried on with. I'm willing to create and send in the patches.
Why not? The config system is changing so much between 2.4 and 2.5 anyway, so any re-organisation like that might as well be done in one go now, rather than during the 2.7 development cycle.
Oh, except that we are in a feature freeze :-), but that doesn't seem to have affected anything else. Infact, I think the current state should be called a
"feature latent-heat-transition-between-melted-and-frozen".
John.
Quoted 12 lines
Quoted 10 lines
It has been a long-time tradition that no "real tunable options" are present in the top level of the kernel config menu. I reckon this has to do with an inherent limitation of the original config subsystem.
While converting the way submenus appear in menuconfig depending on their main, parent config option, I stumbled upon certain subsystems (such as MTD or IrDA) that should clearly have an on/off switch directly in the main menu so that one doesn't have to enter the corresponding submenus to even see if they're enabled or disabled.
Quoted 8 lines
Quoted 4 lines
Since the new kernel configurator would have no problems with such a setup, I'm posting this RFC to get the general opinion on whether this should be carried on with. I'm willing to create and send in the patches.
Why not? The config system is changing so much between 2.4 and 2.5 anyway, so any re-organisation like that might as well be done in one go now, rather than during the 2.7 development cycle.
Well, you see, when I wrote "long-time tradition" above, I actually meant "I've never seen it work differently and it's been *some* years," so I don't want to just go ahead, as I can imagine there might be people with very valid reasons for why this should not be done.
One convenient aspect of this idea is that "make oldconfig" would still work because most of the subsystems already have their main on/off switch the config keyword of which wouldn't change -- it would merely be moved.
Signature · 1 line
Tomas Szepe <[email protected]>
Hi,
Quoted 10 lines · Tomas Szepe
While converting the way submenus appear in menuconfig depending on their main, parent config option, I stumbled upon certain subsystems (such as MTD or IrDA) that should clearly have an on/off switch directly in the main menu so that one doesn't have to enter the corresponding submenus to even see if they're enabled or disabled.
Since the new kernel configurator would have no problems with such a setup, I'm posting this RFC to get the general opinion on whether this should be carried on with. I'm willing to create and send in the patches.
While all config programs should be able to handle this, it might look a bit strange. Especially the split view of xconfig relies a bit on the current organisation of the config data.
My idea to handle this would be to turn e.g.:
menu "Memory Technology Devices (MTD)"
config MTD
tristate "Memory Technology Device (MTD) support"
into something like this:
menuconfig MTD
tristate "Memory Technology Device (MTD) support"
This would give the front ends the most flexibility. The required changes are quite small, so it should be doable for 2.6. I'm not completely sure about the syntax yet, but above is the most likely version.
bye, Roman
Quoted 25 lines
Quoted 10 lines
While converting the way submenus appear in menuconfig depending on their main, parent config option, I stumbled upon certain subsystems (such as MTD or IrDA) that should clearly have an on/off switch directly in the main menu so that one doesn't have to enter the corresponding submenus to even see if they're enabled or disabled.
Since the new kernel configurator would have no problems with such a setup, I'm posting this RFC to get the general opinion on whether this should be carried on with. I'm willing to create and send in the patches.
While all config programs should be able to handle this, it might look a bit strange. Especially the split view of xconfig relies a bit on the current organisation of the config data.
My idea to handle this would be to turn e.g.:menu "Memory Technology Devices (MTD)"
config MTD
tristate "Memory Technology Device (MTD) support"into something like this:
Quoted 7 lines
menuconfig MTD
tristate "Memory Technology Device (MTD) support"This would give the front ends the most flexibility. The required changes are quite small, so it should be doable for 2.6. I'm not completely sure about the syntax yet, but above is the most likely version.
If I understand you correctly, what you are proposing is equivalent to how the following currently works:
config MTD
tristate "Memory Technology Device (MTD) support"
menu "Memory Technology Device (MTD) support"
depends on MTD
...
endmenu
It seems to me the infrastructure you've provided by kconfig is completely sufficient -- it's the config frontends that would require minor updates (xconfig mainly, menuconfig seems to be working nicely -- at least with the setup I outlined above).
Signature · 1 line
Tomas Szepe <[email protected]>
Hi,
Quoted 9 lines · Tomas Szepe
If I understand you correctly, what you are proposing is equivalent to how the following currently works:
config MTD
tristate "Memory Technology Device (MTD) support"menu "Memory Technology Device (MTD) support"
depends on MTD
Quoted 8 lines
...
endmenu
It seems to me the infrastructure you've provided by kconfig is completely sufficient -- it's the config frontends that would require minor updates (xconfig mainly, menuconfig seems to be working nicely -- at least with the setup I outlined above).
Have you tried this with xconfig? What do you mean with "minor updates"? I don't want to add some special magic, I'd rather make this explicit in the syntax.
bye, Roman
PATCH 1/1 menuconfig support for top-level config menu dependencies
In reply to Tomas SzepeHi,
Below is a first version, which implements the menuconfig keyword and makes use of at two places. The behaviour of 'make config' is still the same, but menuconfig and xconfig look a bit different. Comments welcome.
bye, Roman
drivers/mtd/Kconfig +13 -22
@@ -1,8 +1,6 @@ # $Id: Config.in,v 1.74 2002/04/23 13:52:14 mag Exp $ -menu "Memory Technology Devices (MTD)" - -config MTD +menuconfig MTD tristate "Memory Technology Device (MTD) support" help Memory Technology Devices are flash, RAM and similar chips, often
@@ -13,9 +11,10 @@ them. It will also allow you to select individual drivers for particular hardware and users of MTD devices. If unsure, say N. +if MTD + config MTD_DEBUG bool "Debugging" - depends on MTD help This turns on low-level debugging for the entire MTD sub-system. Normally, you should say 'N'.
@@ -29,7 +28,6 @@ config MTD_PARTITIONS tristate "MTD partitioning support" - depends on MTD help If you have a device which needs to divide its flash chip(s) up into multiple 'partitions', each of which appears to the user as
@@ -40,15 +38,6 @@ devices. Partitioning on NFTL 'devices' is a different - that's the 'normal' form of partitioning used on a block device. -config MTD_CONCAT - tristate "MTD concatenating support" - depends on MTD - help - Support for concatenating several MTD devices into a single - (virtual) one. This allows you to have -for example- a JFFS(2) - file system spanning multiple physical flash chips. If unsure, - say 'Y'. - config MTD_REDBOOT_PARTS tristate "RedBoot partition table parsing" depends on MTD_PARTITIONS
@@ -121,12 +110,18 @@ for your particular device. It won't happen automatically. The 'armflash' map driver (CONFIG_MTD_ARMFLASH) does this, for example. +config MTD_CONCAT + tristate "MTD concatenating support" + help + Support for concatenating several MTD devices into a single + (virtual) one. This allows you to have -for example- a JFFS(2) + file system spanning multiple physical flash chips. If unsure, + say 'Y'. + comment "User Modules And Translation Layers" - depends on MTD config MTD_CHAR tristate "Direct char device access to MTD devices" - depends on MTD help This provides a character device for each MTD device present in the system, allowing the user to read and write directly to the
@@ -135,7 +130,6 @@ config MTD_BLOCK tristate "Caching block device access to MTD devices" - depends on MTD ---help--- Although most flash chips have an erase size too large to be useful as block devices, it is possible to use MTD devices which are based
@@ -157,7 +151,7 @@ config MTD_BLOCK_RO tristate "Readonly block device access to MTD devices" - depends on MTD_BLOCK!=y && MTD + depends on MTD_BLOCK!=y help This allows you to mount read-only file systems (such as cramfs) from an MTD device, without the overhead (and danger) of the caching
@@ -168,7 +162,6 @@ config FTL tristate "FTL (Flash Translation Layer) support" - depends on MTD ---help--- This provides support for the original Flash Translation Layer which is part of the PCMCIA specification. It uses a kind of pseudo-
@@ -184,7 +177,6 @@ config NFTL tristate "NFTL (NAND Flash Translation Layer) support" - depends on MTD ---help--- This provides support for the NAND Flash Translation Layer which is used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
@@ -215,5 +207,4 @@ source "drivers/mtd/nand/Kconfig" -endmenu - +endif
drivers/mtd/chips/Kconfig +3 -9
@@ -2,11 +2,9 @@ # $Id: Config.in,v 1.12 2001/09/23 15:35:21 dwmw2 Exp $ menu "RAM/ROM/Flash chip drivers" - depends on MTD!=n config MTD_CFI tristate "Detect flash chips by Common Flash Interface (CFI) probe" - depends on MTD help The Common Flash Interface specification was developed by Intel, AMD and other flash manufactures that provides a universal method
@@ -18,7 +16,6 @@ #dep_tristate ' Detect non-CFI Intel-compatible flash chips' CONFIG_MTD_INTELPROBE $CONFIG_MTD config MTD_JEDECPROBE tristate "Detect non-CFI AMD/JEDEC-compatible flash chips" - depends on MTD help This option enables JEDEC-style probing of flash chips which are not compatible with the Common Flash Interface, but will use the common
@@ -149,21 +146,18 @@ config MTD_RAM tristate "Support for RAM chips in bus mapping" - depends on MTD help This option enables basic support for RAM chips accessed through a bus mapping driver. config MTD_ROM tristate "Support for ROM chips in bus mapping" - depends on MTD help This option enables basic support for ROM chips accessed through a bus mapping driver. config MTD_ABSENT tristate "Support for absent chips in bus mapping" - depends on MTD help This option enables support for a dummy probing driver used to allocated placeholder MTD devices on systems that have socketed
@@ -185,7 +179,7 @@ config MTD_AMDSTD tristate "AMD compatible flash chip support (non-CFI)" - depends on MTD && MTD_OBSOLETE_CHIPS + depends on MTD_OBSOLETE_CHIPS help This option enables support for flash chips using AMD-compatible commands, including some which are not CFI-compatible and hence
@@ -195,7 +189,7 @@ config MTD_SHARP tristate "pre-CFI Sharp chip support" - depends on MTD && MTD_OBSOLETE_CHIPS + depends on MTD_OBSOLETE_CHIPS help This option enables support for flash chips using Sharp-compatible commands, including some which are not CFI-compatible and hence
@@ -203,7 +197,7 @@ config MTD_JEDEC tristate "JEDEC device support" - depends on MTD && MTD_OBSOLETE_CHIPS + depends on MTD_OBSOLETE_CHIPS help Enable older older JEDEC flash interface devices for self programming flash. It is commonly used in older AMD chips. It is
drivers/mtd/devices/Kconfig +2 -9
@@ -2,11 +2,10 @@ # $Id: Config.in,v 1.5 2001/09/23 15:33:10 dwmw2 Exp $ menu "Self-contained MTD device drivers" - depends on MTD!=n config MTD_PMC551 tristate "Ramix PMC551 PCI Mezzanine RAM card support" - depends on MTD && PCI + depends on PCI ---help--- This provides a MTD device driver for the Ramix PMC551 RAM PCI card from Ramix Inc. <http://www.ramix.com/products/memory/pmc551.html>.
@@ -40,7 +39,6 @@ config MTD_SLRAM tristate "Uncached system RAM" - depends on MTD help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to
@@ -48,7 +46,7 @@ config MTD_LART tristate "28F160xx flash driver for LART" - depends on SA1100_LART && MTD + depends on SA1100_LART help This enables the flash driver for LART. Please note that you do not need any mapping/chip driver for LART. This one does it all
@@ -56,7 +54,6 @@ config MTD_MTDRAM tristate "Test driver using RAM" - depends on MTD help This enables a test MTD device driver which uses vmalloc() to provide storage. You probably want to say 'N' unless you're
@@ -96,7 +93,6 @@ config MTD_BLKMTD tristate "MTD emulation using block device" - depends on MTD help This driver allows a block device to appear as an MTD. It would generally be used in the following cases:
@@ -110,14 +106,12 @@ config MTD_DOC1000 tristate "M-Systems Disk-On-Chip 1000" - depends on MTD help This provides an MTD device driver for the M-Systems DiskOnChip 1000 devices, which are obsolete so you probably want to say 'N'. config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium" - depends on MTD ---help--- This provides an MTD device driver for the M-Systems DiskOnChip 2000 and Millennium devices. Originally designed for the DiskOnChip
@@ -134,7 +128,6 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (see help)" - depends on MTD ---help--- This provides an alternative MTD device driver for the M-Systems DiskOnChip Millennium devices. Use this if you have problems with
drivers/mtd/maps/Kconfig +2 -3
@@ -2,7 +2,6 @@ # $Id: Config.in,v 1.16 2001/09/19 18:28:37 dwmw2 Exp $ menu "Mapping drivers for chip access" - depends on MTD!=n config MTD_PHYSMAP tristate "CFI Flash device in physical memory map"
@@ -330,7 +329,7 @@ # This needs CFI or JEDEC, depending on the cards found. config MTD_PCI tristate "PCI MTD driver" - depends on MTD && PCI + depends on PCI help Mapping for accessing flash devices on add-in cards like the Intel XScale IQ80310 card, and the Intel EBSA285 card in blank ROM programming mode
@@ -340,7 +339,7 @@ config MTD_PCMCIA tristate "PCMCIA MTD driver" - depends on MTD && PCMCIA + depends on PCMCIA help Map driver for accessing PCMCIA linear flash memory cards. These cards are usually around 4-16MiB in size. This does not include
drivers/parport/Kconfig +11 -21
@@ -5,9 +5,7 @@ # Parport configuration. # -menu "Parallel port support" - -config PARPORT +menuconfig PARPORT tristate "Parallel port support" ---help--- If you want to use devices connected to your machine's parallel port
@@ -34,9 +32,10 @@ If unsure, say Y. +if PARPORT + config PARPORT_PC tristate "PC-style hardware" - depends on PARPORT ---help--- You should say Y here if you have a PC-style parallel port. All IBM PC compatible computers and some Alphas have PC-style
@@ -51,15 +50,9 @@ If unsure, say Y. -config PARPORT_PC_CML1 - tristate - depends on PARPORT!=n && PARPORT_PC!=n - default PARPORT_PC if SERIAL_8250=y - default m if SERIAL_8250=m - config PARPORT_SERIAL tristate "Multi-IO cards (parallel and serial)" - depends on SERIAL_8250!=n && PARPORT_PC_CML1 + depends on SERIAL_8250 && PARPORT_PC help This adds support for multi-IO PCI cards that have parallel and serial ports. You should say Y or M here. If you say M, the module
@@ -88,18 +81,18 @@ config PARPORT_PC_PCMCIA tristate "Support for PCMCIA management for PC-style ports" - depends on PARPORT!=n && HOTPLUG && (PCMCIA!=n && PARPORT_PC=m && PARPORT_PC || PARPORT_PC=y && PCMCIA) + depends on PCMCIA && PARPORT_PC help Say Y here if you need PCMCIA support for your PC-style parallel ports. If unsure, say N. config PARPORT_ARC tristate "Archimedes hardware" - depends on ARM && PARPORT + depends on ARM config PARPORT_AMIGA tristate "Amiga builtin port" - depends on AMIGA && PARPORT + depends on AMIGA help Say Y here if you need support for the parallel port hardware on Amiga machines. This code is also available as a module (say M),
@@ -107,7 +100,7 @@ config PARPORT_MFC3 tristate "Multiface III parallel port" - depends on AMIGA && ZORRO && PARPORT + depends on AMIGA && ZORRO help Say Y here if you need parallel port support for the MFC3 card. This code is also available as a module (say M), called
@@ -115,7 +108,7 @@ config PARPORT_ATARI tristate "Atari hardware" - depends on ATARI && PARPORT + depends on ATARI help Say Y here if you need support for the parallel port hardware on Atari machines. This code is also available as a module (say M),
@@ -128,7 +121,7 @@ config PARPORT_SUNBPP tristate "Sparc hardware (EXPERIMENTAL)" - depends on SBUS && EXPERIMENTAL && PARPORT + depends on SBUS && EXPERIMENTAL help This driver provides support for the bidirectional parallel port found on many Sun machines. Note that many of the newer Ultras
@@ -138,7 +131,6 @@ # support for loading any others. Defeat this if the user is keen. config PARPORT_OTHER bool "Support foreign hardware" - depends on PARPORT help Say Y here if you want to be able to load driver modules to support other non-standard types of parallel ports. This causes a
@@ -146,7 +138,6 @@ config PARPORT_1284 bool "IEEE 1284 transfer modes" - depends on PARPORT help If you have a printer that supports status readback or device ID, or want to use a device that uses enhanced parallel port transfer modes
@@ -154,5 +145,4 @@ transfer modes. Also say Y if you want device ID information to appear in /proc/sys/dev/parport/*/autoprobe*. It is safe to say N. -endmenu - +endif
scripts/kconfig/expr.h +3 -1
@@ -155,9 +155,11 @@#define for_all_properties (sym, st, tok) \ for (st = sym->prop; st; st = st->next) \ if (st->type == (tok)) -#define for_all_prompts (sym, st) for_all_properties(sym, st, P_PROMPT)#define for_all_defaults (sym, st) for_all_properties(sym, st, P_DEFAULT)#define for_all_choices (sym, st) for_all_properties(sym, st, P_CHOICE) +#define for_all_prompts (sym, st) \ + for (st = sym->prop; st; st = st->next) \ + if (st->text)struct menu {struct menu *next;
scripts/kconfig/lex.zconf.c_shipped +173 -124
762 lines not on this page · raw message
scripts/kconfig/mconf.c +15 -3
@@ -303,7 +303,7 @@ menu->data ?"-->" :"++>" , indent + 1, ' ', prompt); }else { -if (menu->parent != &rootmenu) +//if (menu->parent != &rootmenu) cprint1 (" %*c" , indent +1 ,' ' );cprint1 ("%s --->" , prompt); }
@@ -373,6 +373,11 @@ }cprint_done (); }else { +if (menu == current_menu) { +cprint (":%p" , menu); +cprint ("---%*c%s" , indent +1 ,' ' ,menu_get_prompt (menu)); + goto conf_childs; + } child_count++; val =sym_get_tristate_value (sym);if (sym_is_choice_value (sym) && val == yes) {
@@ -407,6 +412,11 @@ }cprint1 ("%*c%s%s" , indent +1 ,' ' ,menu_get_prompt (menu),sym_has_value (sym) ?"" :" (NEW)" ); +if (menu->prompt->type ==P_MENU ) { +cprint1 (" --->" ); +cprint_done (); +return ; + }cprint_done (); }
@@ -445,9 +455,9 @@cprint (":" );cprint ("--- " );cprint ("L" ); -cprint ("Load an Alternate Configuration File" ); +cprint (" Load an Alternate Configuration File" );cprint ("S" ); -cprint ("Save Configuration to an Alternate File" ); +cprint (" Save Configuration to an Alternate File" ); } stat =exec_conf ();if (stat <0 )
@@ -484,6 +494,8 @@case 't' :if (sym_is_choice (sym) &&sym_get_tristate_value (sym) == yes)conf_choice (submenu); +else if (submenu->prompt->type ==P_MENU ) +conf (submenu);break ;case 's' :conf_string (submenu);
scripts/kconfig/zconf.l +2 -1
@@ -96,6 +96,7 @@ "endchoice" BEGIN(PARAM); return T_ENDCHOICE; "comment" BEGIN(PARAM); return T_COMMENT; "config" BEGIN(PARAM); return T_CONFIG; + "menuconfig" BEGIN(PARAM); return T_MENUCONFIG; "help" BEGIN(PARAM); return T_HELP; "if" BEGIN(PARAM); return T_IF; "endif" BEGIN(PARAM); return T_ENDIF;
@@ -208,7 +209,7 @@ } } - \n/[^ \t\n] { + [ \t]*\n/[^ \t\n] { current_file->lineno++; zconf_endhelp(); return T_HELPTEXT;
scripts/kconfig/zconf.tab.c_shipped +310 -280
973 lines not on this page · raw message
scripts/kconfig/zconf.y +22 -2
@@ -27,7 +27,7 @@ #define YYERROR_VERBOSE %} -%expect 36 +%expect 40 %union {
@@ -46,6 +46,7 @@ %token T_ENDCHOICE %token T_COMMENT %token T_CONFIG +%token T_MENUCONFIG %token T_HELP %token <string> T_HELPTEXT %token T_IF
@@ -104,12 +105,13 @@ if_stmt | comment_stmt | config_stmt + | menuconfig_stmt | source_stmt | nl_or_eof ; -/* config entry */ +/* config/menuconfig entry */ config_entry_start: T_CONFIG T_WORD {
@@ -125,6 +127,24 @@ printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno()); }; +menuconfig_entry_start: T_MENUCONFIG T_WORD +{ + struct symbol *sym = sym_lookup($2, 0); + sym->flags |= SYMBOL_OPTIONAL; + menu_add_entry(sym); + printd(DEBUG_PARSE, "%s:%d:menuconfig %s\n", zconf_curname(), zconf_lineno(), $2); +}; + +menuconfig_stmt: menuconfig_entry_start T_EOL config_option_list +{ + if (current_entry->prompt) + current_entry->prompt->type = P_MENU; + else + zconfprint("warning: menuconfig statement without prompt"); + menu_end_entry(); + printd(DEBUG_PARSE, "%s:%d:endconfig\n", zconf_curname(), zconf_lineno()); +}; + config_option_list: /* empty */ | config_option_list config_option T_EOL
Re: [PATCH] menuconfig support for top-level config menu dependencies
Quoted 5 lines
Below is a first version, which implements the menuconfig keyword and makes use of at two places. The behaviour of 'make config' is still the same
That's a good thing, we probably want a few menus look exactly as before.
Quoted 2 lines
but menuconfig and xconfig look a bit different.
Comments welcome.
Looking good. Can you please rediff against current 2.5?
Signature · 1 line
Tomas Szepe <[email protected]>
Re: [PATCH] menuconfig support for top-level config menu dependencies
Quoted 9 lines
Quoted 5 lines
Below is a first version, which implements the menuconfig keyword and makes use of at two places. The behaviour of 'make config' is still the same
That's a good thing, we probably want a few menus look exactly as before.
*BZZZZZZZZZZ*
Eeee. Sorry, I thought you were mentioning the config language keywords.
This is one of my teeth aching badly. The doctor told me to turn up monday morning. :(
Signature · 1 line
Tomas Szepe <[email protected]>
Menuconfig support for top-level config menu dependencies
In reply to Roman ZippelQuoted 6 lines
Below is a first version, which implements the menuconfig keyword and makes use of at two places. The behaviour of 'make config' is still the same, but menuconfig and xconfig look a bit different. Comments welcome.
Okay, here's Roman's update rediffed against bkcurrent. Linus and others, can you have a look at what this gives us and let us know what you think? Thanks,
Signature · 1 line
Tomas Szepe <[email protected]>