[RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Robert P. J. Day]

  i've posted on this before so here's a slightly-updated patch that
uses the kbuild "menuconfig" feature to make numerous entries under
the Device drivers menu selectable on the spot.  if folks think this
is a good idea, what's the best way to get it in?

  i could officially submit the patch as is or, if that's too
wide-sweeping since it hits a lot of subsystems, leave it up to the
individual subsystem maintainers to decide for themselves and submit
their own patch.

  (the patch below modifies those entries for which a "menuconfig"
entry was immediately obvious and shouldn't affect any of the
underlying logic.  that's why some entries were deliberately left out
of the patch, at least for now.)


 drivers/ata/Kconfig         |    8 ++------
 drivers/connector/Kconfig   |    8 ++++----
 drivers/dma/Kconfig         |   10 +++++-----
 drivers/edac/Kconfig        |    8 ++++----
 drivers/hwmon/Kconfig       |    8 ++++----
 drivers/i2c/Kconfig         |    9 ++++-----
 drivers/ide/Kconfig         |    6 +-----
 drivers/ieee1394/Kconfig    |    7 ++++---
 drivers/infiniband/Kconfig  |   10 +++++-----
 drivers/isdn/Kconfig        |    9 ++++-----
 drivers/leds/Kconfig        |    9 +++------
 drivers/md/Kconfig          |    8 ++++----
 drivers/message/i2o/Kconfig |   12 +++++-------
 drivers/mmc/Kconfig         |    8 ++++----
 drivers/mtd/Kconfig         |    8 ++++----
 drivers/parport/Kconfig     |    8 ++++----
 drivers/pnp/Kconfig         |    8 ++++----
 drivers/spi/Kconfig         |    8 ++++----
 drivers/telephony/Kconfig   |    9 ++++-----
 drivers/w1/Kconfig          |    8 ++++----
 20 files changed, 77 insertions(+), 92 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 984ab28..a3bdf04 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -2,10 +2,8 @@
 # SATA/PATA driver configuration
 #

-menu "Serial ATA (prod) and Parallel ATA (experimental) drivers"
-
-config ATA
-	tristate "ATA device support"
+menuconfig ATA
+	tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
 	depends on BLOCK
 	depends on !(M32R || M68K) || BROKEN
 	depends on !SUN4 || BROKEN
@@ -519,5 +517,3 @@ config PATA_IXP4XX_CF
 	  If unsure, say N.

 endif
-endmenu
-
diff --git a/drivers/connector/Kconfig b/drivers/connector/Kconfig
index e0bdc0d..9a5a061 100644
--- a/drivers/connector/Kconfig
+++ b/drivers/connector/Kconfig
@@ -1,6 +1,4 @@
-menu "Connector - unified userspace <-> kernelspace linker"
-
-config CONNECTOR
+menuconfig CONNECTOR
 	tristate "Connector - unified userspace <-> kernelspace linker"
 	depends on NET
 	---help---
@@ -10,6 +8,8 @@ config CONNECTOR
 	  Connector support can also be built as a module.  If so, the module
 	  will be called cn.ko.

+if CONNECTOR
+
 config PROC_EVENTS
 	boolean "Report process events to userspace"
 	depends on CONNECTOR=y
@@ -18,4 +18,4 @@ config PROC_EVENTS
 	  Provide a connector that reports process events to userspace. Send
 	  events such as fork, exec, id change (uid, gid, suid, etc), and exit.

-endmenu
+endif
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 30d021d..b1fb8c0 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -2,14 +2,14 @@
 # DMA engine configuration
 #

-menu "DMA Engine support"
-
-config DMA_ENGINE
-	bool "Support for DMA engines"
+menuconfig DMA_ENGINE
+	bool "DMA engine support"
 	---help---
 	  DMA engines offload copy operations from the CPU to dedicated
 	  hardware, allowing the copies to happen asynchronously.

+if DMA_ENGINE
+
 comment "DMA Clients"

 config NET_DMA
@@ -31,4 +31,4 @@ config INTEL_IOATDMA
 	---help---
 	  Enable support for the Intel(R) I/OAT DMA engine.

-endmenu
+endif
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 4f08984..e52e9b0 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -6,10 +6,9 @@
 # $Id: Kconfig,v 1.4.2.7 2005/07/08 22:05:38 dsp_llnl Exp $
 #

-menu 'EDAC - error detection and reporting (RAS) (EXPERIMENTAL)'

-config EDAC
-	tristate "EDAC core system error reporting (EXPERIMENTAL)"
+menuconfig EDAC
+	tristate 'EDAC - error detection and reporting (RAS) (EXPERIMENTAL)'
 	depends on X86 && EXPERIMENTAL
 	help
 	  EDAC is designed to report errors in the core system.
@@ -29,6 +28,7 @@ config EDAC
 	  There is also a mailing list for the EDAC project, which can
 	  be found via the sourceforge page.

+if EDAC

 comment "Reporting subsystems"
 	depends on EDAC
@@ -110,4 +110,4 @@ config EDAC_POLL

 endchoice

-endmenu
+endif
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 891ef6d..7a8afaa 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2,9 +2,7 @@
 # Hardware monitoring chip drivers configuration
 #

-menu "Hardware Monitoring support"
-
-config HWMON
+menuconfig HWMON
 	tristate "Hardware Monitoring support"
 	default y
 	help
@@ -23,6 +21,8 @@ config HWMON
 	  This support can also be built as a module.  If so, the module
 	  will be called hwmon.

+if HWMON
+
 config HWMON_VID
 	tristate
 	default n
@@ -592,4 +592,4 @@ config HWMON_DEBUG_CHIP
 	  a problem with I2C support and want to see more of what is going
 	  on.

-endmenu
+endif
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 11935f6..af35094 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -2,9 +2,7 @@
 # I2C subsystem configuration
 #

-menu "I2C support"
-
-config I2C
+menuconfig I2C
 	tristate "I2C support"
 	---help---
 	  I2C (pronounce: I-square-C) is a slow serial bus protocol used in
@@ -22,6 +20,8 @@ config I2C
 	  This I2C support can also be built as a module.  If so, the module
 	  will be called i2c-core.

+if I2C
+
 config I2C_CHARDEV
 	tristate "I2C device interface"
 	depends on I2C
@@ -73,5 +73,4 @@ config I2C_DEBUG_CHIP
 	  a problem with I2C support and want to see more of what is going
 	  on.

-endmenu
-
+endif
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index 3f82805..cef34d3 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -6,9 +6,7 @@

 if BLOCK

-menu "ATA/ATAPI/MFM/RLL support"
-
-config IDE
+menuconfig IDE
 	tristate "ATA/ATAPI/MFM/RLL support"
 	---help---
 	  If you say Y here, your kernel will be able to manage low cost mass
@@ -1080,6 +1078,4 @@ config BLK_DEV_HD

 endif

-endmenu
-
 endif
diff --git a/drivers/ieee1394/Kconfig b/drivers/ieee1394/Kconfig
index e7d5657..75d07e5 100644
--- a/drivers/ieee1394/Kconfig
+++ b/drivers/ieee1394/Kconfig
@@ -1,8 +1,7 @@
 # -*- shell-script -*-

-menu "IEEE 1394 (FireWire) support"

-config IEEE1394
+menuconfig IEEE1394
 	tristate "IEEE 1394 (FireWire) support"
 	depends on PCI || BROKEN
 	select NET
@@ -19,6 +18,8 @@ config IEEE1394
 	  To compile this driver as a module, say M here: the
 	  module will be called ieee1394.

+if IEEE1394
+
 comment "Subsystem Options"
 	depends on IEEE1394

@@ -175,4 +176,4 @@ config IEEE1394_RAWIO
 	  To compile this driver as a module, say M here: the
 	  module will be called raw1394.

-endmenu
+endif
diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index 9edface..6582f51 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -1,13 +1,13 @@
-menu "InfiniBand support"
-
-config INFINIBAND
-	depends on PCI || BROKEN
+menuconfig INFINIBAND
 	tristate "InfiniBand support"
+	depends on PCI || BROKEN
 	---help---
 	  Core support for InfiniBand (IB).  Make sure to also select
 	  any protocols you wish to use as well as drivers for your
 	  InfiniBand hardware.

+if INFINIBAND
+
 config INFINIBAND_USER_MAD
 	tristate "InfiniBand userspace MAD support"
 	depends on INFINIBAND
@@ -45,4 +45,4 @@ source "drivers/infiniband/ulp/srp/Kconfig"

 source "drivers/infiniband/ulp/iser/Kconfig"

-endmenu
+endif
diff --git a/drivers/isdn/Kconfig b/drivers/isdn/Kconfig
index c90afee..f7bf323 100644
--- a/drivers/isdn/Kconfig
+++ b/drivers/isdn/Kconfig
@@ -2,9 +2,7 @@
 # ISDN device configuration
 #

-menu "ISDN subsystem"
-
-config ISDN
+menuconfig ISDN
 	tristate "ISDN support"
 	depends on NET
 	---help---
@@ -20,6 +18,8 @@ config ISDN

 	  Select this option if you want your kernel to support ISDN.

+if ISDN
+

 menu "Old ISDN4Linux"
 	depends on NET && ISDN
@@ -63,5 +63,4 @@ source "drivers/isdn/capi/Kconfig"

 source "drivers/isdn/hardware/Kconfig"

-endmenu
-
+endif
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7399ba7..94ebdf5 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -1,7 +1,4 @@
-
-menu "LED devices"
-
-config NEW_LEDS
+menuconfig NEW_LEDS
 	bool "LED Support"
 	help
 	  Say Y to enable Linux LED support.  This allows control of supported
@@ -9,6 +6,7 @@ config NEW_LEDS

 	  This is not related to standard keyboard LEDs which are controlled
 	  via the input system.
+if NEW_LEDS

 config LEDS_CLASS
 	tristate "LED Class Support"
@@ -115,5 +113,4 @@ config LEDS_TRIGGER_HEARTBEAT
 	  load average.
 	  If unsure, say Y.

-endmenu
-
+endif
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 4540ade..b12b33b 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -4,14 +4,14 @@

 if BLOCK

-menu "Multi-device support (RAID and LVM)"
-
-config MD
+menuconfig MD
 	bool "Multiple devices driver support (RAID and LVM)"
 	help
 	  Support multiple physical spindles through a single logical device.
 	  Required for RAID and logical volume management.

+if MD
+
 config BLK_DEV_MD
 	tristate "RAID support"
 	depends on MD
@@ -262,6 +262,6 @@ config DM_MULTIPATH_EMC
 	---help---
 	  Multipath support for EMC CX/AX series hardware.

-endmenu
+endif

 endif
diff --git a/drivers/message/i2o/Kconfig b/drivers/message/i2o/Kconfig
index 6443392..6177faa 100644
--- a/drivers/message/i2o/Kconfig
+++ b/drivers/message/i2o/Kconfig
@@ -1,8 +1,5 @@
-
-menu "I2O device support"
-
-config I2O
-	tristate "I2O support"
+menuconfig I2O
+	tristate "I2O device support"
 	depends on PCI
 	---help---
 	  The Intelligent Input/Output (I2O) architecture allows hardware
@@ -24,6 +21,8 @@ config I2O

 	  If unsure, say N.

+if I2O
+
 config I2O_LCT_NOTIFY_ON_CHANGES
 	bool "Enable LCT notification"
 	depends on I2O
@@ -122,5 +121,4 @@ config I2O_PROC
 	  To compile this support as a module, choose M here: the
 	  module will be called i2o_proc.

-endmenu
-
+endif
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 4224686..841524a 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -2,15 +2,15 @@
 # MMC subsystem configuration
 #

-menu "MMC/SD Card support"

-config MMC
-	tristate "MMC support"
+menuconfig MMC
+	tristate "MMC/SD Card support"
 	help
 	  MMC is the "multi-media card" bus protocol.

 	  If you want MMC support, you should say Y here and also
 	  to the specific driver for your MMC interface.
+if MMC

 config MMC_DEBUG
 	bool "MMC debugging"
@@ -125,4 +125,4 @@ config MMC_TIFM_SD
           To compile this driver as a module, choose M here: the
 	  module will be called tifm_sd.

-endmenu
+endif
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index a304b34..3c9ae5b 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -1,8 +1,6 @@
 # $Id: Kconfig,v 1.11 2005/11/07 11:14:19 gleixner 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,6 +11,8 @@ config MTD
 	  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
@@ -281,5 +281,5 @@ source "drivers/mtd/nand/Kconfig"

 source "drivers/mtd/onenand/Kconfig"

-endmenu
+endif

diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
index 36c6a1b..7a3ed1c 100644
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -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
@@ -32,6 +30,8 @@ config PARPORT

 	  If unsure, say Y.

+if PARPORT
+
 config PARPORT_PC
 	tristate "PC-style hardware"
 	depends on PARPORT && (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV
@@ -158,5 +158,5 @@ config PARPORT_1284
 config PARPORT_NOT_PC
 	bool

-endmenu
+endif

diff --git a/drivers/pnp/Kconfig b/drivers/pnp/Kconfig
index c514320..ec7ab40 100644
--- a/drivers/pnp/Kconfig
+++ b/drivers/pnp/Kconfig
@@ -2,9 +2,7 @@
 # Plug and Play configuration
 #

-menu "Plug and Play support"
-
-config PNP
+menuconfig PNP
 	bool "Plug and Play support"
 	depends on ISA || ACPI
 	---help---
@@ -21,6 +19,8 @@ config PNP

 	  If unsure, say Y.

+if PNP
+
 config PNP_DEBUG
 	bool "PnP Debug Messages"
 	depends on PNP
@@ -37,5 +37,5 @@ source "drivers/pnp/pnpbios/Kconfig"

 source "drivers/pnp/pnpacpi/Kconfig"

-endmenu
+endif

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d895a1a..1b44244 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -5,9 +5,7 @@
 # nobody's needed a slave side API yet.  The master-role API is not
 # fully appropriate there, so it'd need some thought to do well.
 #
-menu "SPI support"
-
-config SPI
+menuconfig SPI
 	bool "SPI support"
 	help
 	  The "Serial Peripheral Interface" is a low level synchronous
@@ -27,6 +25,8 @@ config SPI
 	  (half duplex), SSP, SSI, and PSP.  This driver framework should
 	  work with most such devices and controllers.

+if SPI
+
 config SPI_DEBUG
 	boolean "Debug support for SPI drivers"
 	depends on SPI && DEBUG_KERNEL
@@ -129,5 +129,5 @@ comment "SPI Protocol Masters"

 # (slave support would go here)

-endmenu # "SPI support"
+endif

diff --git a/drivers/telephony/Kconfig b/drivers/telephony/Kconfig
index 7625b18..d123fa1 100644
--- a/drivers/telephony/Kconfig
+++ b/drivers/telephony/Kconfig
@@ -2,9 +2,7 @@
 # Telephony device configuration
 #

-menu "Telephony Support"
-
-config PHONE
+menuconfig PHONE
 	tristate "Linux telephony support"
 	---help---
 	  Say Y here if you have a telephony card, which for example allows
@@ -16,6 +14,8 @@ config PHONE
 	  To compile this driver as a module, choose M here: the
 	  module will be called phonedev.

+if PHONE
+
 config PHONE_IXJ
 	tristate "QuickNet Internet LineJack/PhoneJack support"
 	depends on PHONE
@@ -43,5 +43,4 @@ config PHONE_IXJ_PCMCIA
 	  cards manufactured by Quicknet Technologies, Inc.  This changes the
 	  card initialization code to work with the card manager daemon.

-endmenu
-
+endif
diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
index c287a9a..63c9c82 100644
--- a/drivers/w1/Kconfig
+++ b/drivers/w1/Kconfig
@@ -1,6 +1,4 @@
-menu "Dallas's 1-wire bus"
-
-config W1
+menuconfig W1
 	tristate "Dallas's 1-wire support"
 	---help---
 	  Dallas' 1-wire bus is useful to connect slow 1-pin devices
@@ -11,6 +9,8 @@ config W1
 	  This W1 support can also be built as a module.  If so, the module
 	  will be called wire.ko.

+if W1
+
 config W1_CON
 	depends on CONNECTOR && W1
 	bool "Userspace communication over connector"
@@ -26,4 +26,4 @@ config W1_CON
 source drivers/w1/masters/Kconfig
 source drivers/w1/slaves/Kconfig

-endmenu
+endif

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Stefan Richter]

Robert P. J. Day wrote on 2006-12-14:
>   i've posted on this before so here's a slightly-updated patch that
> uses the kbuild "menuconfig" feature to make numerous entries under
> the Device drivers menu selectable on the spot.

Works for me, but I don't see a lot of benefit from it. Actually I see
two disadvantages of the patch:

 - Without the patch, the choice of y/m/n for a subsystem and the help
text is put aside into the submenu. I find this current layout simpler
and quieter.

 - There are two out-of-tree FireWire drivers for special purposes (one
bus sniffer, one remote debugging aid) which might perhaps be candidates
for integration into mainline. These drivers do not use the ieee1394
base driver. (They just don't need to.) With your patch, disabling the
subsystem menu would not only disable the subsystem core driver (which
is correct) but would also hide the choice for such extra drivers which
do not need the core driver. Or vice versa, enabling the submenu would
enable the core driver, even though not all subsystem choices need the
core driver.

The latter point could be worked around by creating an extra hidden
option for the core driver which is SELECTed by the subsystem drivers
which need it. But this would put the user out of control and would
clash with the fact that there are further configuration options for the
core driver itself.

(Sorry if these things were already discussed when you posted the patch
before, I missed that.)

> if folks think this is a good idea, what's the best way to get it in?
> 
>   i could officially submit the patch as is or, if that's too
> wide-sweeping since it hits a lot of subsystems, leave it up to the
> individual subsystem maintainers to decide for themselves and submit
> their own patch.

This kind of patch can certainly be integrated as one big chunk. However
the points I made above are more valid for some subsystems than others.

>   (the patch below modifies those entries for which a "menuconfig"
> entry was immediately obvious and shouldn't affect any of the
> underlying logic.  that's why some entries were deliberately left out
> of the patch, at least for now.)
> 
> 
>  drivers/ata/Kconfig         |    8 ++------
>  drivers/connector/Kconfig   |    8 ++++----
>  drivers/dma/Kconfig         |   10 +++++-----
>  drivers/edac/Kconfig        |    8 ++++----
>  drivers/hwmon/Kconfig       |    8 ++++----
>  drivers/i2c/Kconfig         |    9 ++++-----
>  drivers/ide/Kconfig         |    6 +-----
>  drivers/ieee1394/Kconfig    |    7 ++++---
>  drivers/infiniband/Kconfig  |   10 +++++-----
>  drivers/isdn/Kconfig        |    9 ++++-----
>  drivers/leds/Kconfig        |    9 +++------
>  drivers/md/Kconfig          |    8 ++++----
>  drivers/message/i2o/Kconfig |   12 +++++-------
>  drivers/mmc/Kconfig         |    8 ++++----
>  drivers/mtd/Kconfig         |    8 ++++----
>  drivers/parport/Kconfig     |    8 ++++----
>  drivers/pnp/Kconfig         |    8 ++++----
>  drivers/spi/Kconfig         |    8 ++++----
>  drivers/telephony/Kconfig   |    9 ++++-----
>  drivers/w1/Kconfig          |    8 ++++----
>  20 files changed, 77 insertions(+), 92 deletions(-)
> 
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 984ab28..a3bdf04 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -2,10 +2,8 @@
>  # SATA/PATA driver configuration
>  #
> 
> -menu "Serial ATA (prod) and Parallel ATA (experimental) drivers"
> -
> -config ATA
> -	tristate "ATA device support"
> +menuconfig ATA
> +	tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
>  	depends on BLOCK
>  	depends on !(M32R || M68K) || BROKEN
>  	depends on !SUN4 || BROKEN
> @@ -519,5 +517,3 @@ config PATA_IXP4XX_CF
>  	  If unsure, say N.
> 
>  endif
> -endmenu
> -
[...]


-- 
Stefan Richter
-=====-=-==- ==-- =----
http://arcgraph.de/sr/

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Jan Engelhardt]

On Dec 16 2006 11:52, Stefan Richter wrote:
>Robert P. J. Day wrote on 2006-12-14:
>>   i've posted on this before so here's a slightly-updated patch that
>> uses the kbuild "menuconfig" feature to make numerous entries under
>> the Device drivers menu selectable on the spot.
>
>Works for me, but I don't see a lot of benefit from it. Actually I see
>two disadvantages of the patch:
>
> - Without the patch, the choice of y/m/n for a subsystem and the help
>text is put aside into the submenu. I find this current layout simpler
>and quieter.

When using "Help" on a (normal) menu element, the menuconfig help pops up.
(This is probably what you mean.)
This could be changed for menuconfig elements.

> - There are two out-of-tree FireWire drivers for special purposes (one
>bus sniffer, one remote debugging aid) which might perhaps be candidates
>for integration into mainline. These drivers do not use the ieee1394
>base driver. (They just don't need to.) With your patch, disabling the
>subsystem menu would not only disable the subsystem core driver (which
>is correct) but would also hide the choice for such extra drivers which
>do not need the core driver. Or vice versa, enabling the submenu would
>enable the core driver, even though not all subsystem choices need the
>core driver.

And in case there is a

   menu FOO

   config BAR

   config BAZ

   endmenu

just don't convert these to menuconfig. Issue set :)



	-`J'
-- 

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Robert P. J. Day]

On Sat, 16 Dec 2006, Stefan Richter wrote:

> Robert P. J. Day wrote on 2006-12-14:
> >   i've posted on this before so here's a slightly-updated patch
> > that uses the kbuild "menuconfig" feature to make numerous entries
> > under the Device drivers menu selectable on the spot.
>
> Works for me, but I don't see a lot of benefit from it. Actually I
> see two disadvantages of the patch:
>
>  - Without the patch, the choice of y/m/n for a subsystem and the
> help text is put aside into the submenu. I find this current layout
> simpler and quieter.

it's certainly "simpler and quieter" in one sense, but one need only
look at a submenu like "Network device support" to see a very "loud"
menu, so it's not like this patch would be introducing an
unprecedented level of noise.

also, in the Device Drivers menu, i find it slightly annoying that i
have to *enter* a submenu to read its help information.  if i see the
entry, say, "Dallas's 1-wire bus" and i have no idea what that is and
select "Help", i get the generic help screen.  i need to select that
entry and enter the submenu just to read its top-level help.

in any event, i'm sure folks understand what i'm after here.  if
there's a cleaner and more efficient way to do this, that would work
for me.

rday

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Robert P. J. Day]

On Sat, 16 Dec 2006, Stefan Richter wrote:

> Robert P. J. Day wrote on 2006-12-14:
> >   i've posted on this before so here's a slightly-updated patch that
> > uses the kbuild "menuconfig" feature to make numerous entries under
> > the Device drivers menu selectable on the spot.
>
> Works for me, but I don't see a lot of benefit from it. Actually I see
> two disadvantages of the patch:

... snip ...

>  - There are two out-of-tree FireWire drivers for special purposes
> (one bus sniffer, one remote debugging aid) which might perhaps be
> candidates for integration into mainline. These drivers do not use
> the ieee1394 base driver. (They just don't need to.) With your
> patch, disabling the subsystem menu would not only disable the
> subsystem core driver (which is correct) but would also hide the
> choice for such extra drivers which do not need the core driver. Or
> vice versa, enabling the submenu would enable the core driver, even
> though not all subsystem choices need the core driver.

... snip ...

i've noticed this sort of thing before -- submenus containing entries
that don't actually depend on the top-level config variable.  but
which drivers are you talking about here?  i'm looking at the
ieee1394/Kconfig file and every entry in that submenu appears to
depend explicitly on IEEE1394.

note that that patch i submitted earlier didn't try to modify every
single sub-entry under Device Drivers -- only those for which it
seemed that the transformation wouldn't cause *any* change in
functionality.  so if there was something about ieee1394 that didn't
fit the bill, it's because i must have overlooked something.

in any event, as i mentioned earlier, i'm just trying to find a way to
make the menu entries more obvious and more easily selectable, without
having to enter each submenu to see what it represents.  it's quite
possible that a whole new kbuild directive would be useful here.  who
knows?

rday

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Stefan Richter]

Robert P. J. Day wrote:
> On Sat, 16 Dec 2006, Stefan Richter wrote:
>> Works for me, but I don't see a lot of benefit from it. Actually I see
>> two disadvantages of the patch:
> 
> ... snip ...
> 
>>  - There are two out-of-tree FireWire drivers for special purposes
                    ^^^^^^^^^^^
>> (one bus sniffer, one remote debugging aid) which might perhaps be
>> candidates for integration into mainline. These drivers do not use
>> the ieee1394 base driver.
[...]
> i've noticed this sort of thing before -- submenus containing entries
> that don't actually depend on the top-level config variable.  but
> which drivers are you talking about here?

As yet non-existent drivers. (Out-of-tree drivers.)

> i'm looking at the
> ieee1394/Kconfig file and every entry in that submenu appears to
> depend explicitly on IEEE1394.

Correct. What I described is purely hypothetical in case of
drivers/ieee1394. There surely are other submenus with actual
independent entries. But AFAIU you didn't touch such menus of course.

[...]
> in any event, as i mentioned earlier, i'm just trying to find a way to
> make the menu entries more obvious and more easily selectable, without
> having to enter each submenu to see what it represents.
[...]

Yes, this and the points you made in the other post are definitely valid.
-- 
Stefan Richter
-=====-=-==- ==-- =--=-
http://arcgraph.de/sr/

Re: [RFC][PATCH] Make entries in the "Device drivers" menu individually selectable

[Robert P. J. Day]

On Mon, 18 Dec 2006, Stefan Richter wrote:

> Robert P. J. Day wrote:

> [...]
> > in any event, as i mentioned earlier, i'm just trying to find a
> > way to make the menu entries more obvious and more easily
> > selectable, without having to enter each submenu to see what it
> > represents.
> [...]
>
> Yes, this and the points you made in the other post are definitely
> valid.

this is a long-term suggestion, but the easiest solution might be to
introduce a new kbuild directive:  "selectablemenu" or something like
that, with a form similar to:

=================
selectablemenu ISDN
	bool "ISDN support"

config ...
config ...
config ...

endmenu
=================

  the top level entry would be just a yes/no toggle as to whether you
want that support in general, and the internal entries would represent
the submenu and all of them would *automatically* depend on the top
config entry (in this case, ISDN).  and the "help" entry could be
available from that top-level entry without having to enter the
submenu. as opposed to what you need to do now.

  i'm guessing that structure would be sufficient for 90% of the
current menu layouts.  just a thought.

rday