Hi,
Maybe it is a nice enhancement for make menuconfig to more explicitly

give a pop-up or so when someone selects for example a sata controller

while no 'scsi-disk' support was selected?
Folkert van Heusden
--

Multi tail barnamaj mowahib li mora9abat attasjilat wa nataij awamir

al 7asoub. damj, talwin, mora9abat attarchi7 wa ila akhirih.

http://www.vanheusden.com/multitail/

----------------------------------------------------------------------

Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

-

This has also bitten me one or two times. A reasonable way would

be to just select SD automatically for !EMBEDDED
Here's a patch:
-Andi
Select BLK_DEV_SD for all SCSI/libata drivers
This avoid a common user mistake.
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux-2.6.23-rc1-misc/drivers/ata/Kconfig

===================================================================

--- linux-2.6.23-rc1-misc.orig/drivers/ata/Kconfig

+++ linux-2.6.23-rc1-misc/drivers/ata/Kconfig

@@ -42,6 +42,7 @@ config ATA_ACPI
 config SATA_AHCI

 	tristate "AHCI SATA support"

+	select BLK_DEV_SD if !EMBEDDED

 	depends on PCI

 	help

 	  This option enables support for AHCI Serial ATA.

@@ -50,6 +51,7 @@ config SATA_AHCI
 config SATA_SVW

 	tristate "ServerWorks Frodo / Apple K2 SATA support"

+	select BLK_DEV_SD if !EMBEDDED

 	depends on PCI

 	help

 	  This option enables support for Broadcom/Serverworks/Apple K2

@@ -59,6 +61,7 @@ config SATA_SVW
 config ATA_PIIX

 	tristate "Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support"

+	select BLK_DEV_SD if !EMBEDDED

 	depends on PCI

 	help

 	  This option enables support for ICH5/6/7/8 Serial ATA

@@ -69,6 +72,7 @@ config ATA_PIIX
 config SATA_MV

 	tristate "Marvell SATA support (HIGHLY EXPERIMENTAL)"

+	select BLK_DEV_SD if !EMBEDDED

 	depends on PCI && EXPERIMENTAL

 	help

 	  This option enables support for the Marvell Serial ATA family.

@@ -78,6 +82,7 @@ config SATA_MV
 config SATA_NV

 	tristate "NVIDIA SATA support"

+	select BLK_DEV_SD if !EMBEDDED

 	depends on PCI

 	help

 	  This option enables support for NVIDIA Serial ATA.

@@ -86,6 +91,7 @@ config SATA_NV
 config PDC_ADMA

 	tristate "Pacific Digital ADMA support"

+	select BLK_DEV_SD if !EMBEDDED

 	depends on PCI

 	help

 	  This option enables support for Pacific Digital ADMA controllers

@@ -94,6 +100,7 @@ config PDC_ADMA
 config SATA_QSTOR

 	tristate "Pacific Digital SATA QStor support"

+	select BLK_DEV_SD if !EMBEDDED

 	depends on PCI

 	help

 	 ...
[ message continues ]

I can see where you're coming from, but logically, this is wrong.

There's a huge slew of enterprise machines that only have DVD on SATA.

On the other hand, all of these machines will have SCSI disk devices on

various other transports, so no harm is done, it's just an inelegant

solution.
James
-

... and enterprise systems don't really care about a few KB more of code.

In fact you definitely want to have SATA compiled in in case you need
Do you know of a better one?
-Andi

-

Let's step back a moment and consider the actual scale and impact of the

problem at hand.
The vast majority of users are consumers of pre-compiled kernels, built

by People With Clue(tm), who figured this stuff out as soon as it was

introduced.
The current setup expresses the dependencies as they exist -- OPTIONAL

extras, and that is a problem once a year or so, when someone builds

their own kernel but must learn this fact anew.
There is simply no compelling need at all to change things from the

current setup.
Our Kconfig system is for people who already know the kernel, not Aunt

Tillie.
	Jeff
-

We are talking about a patch to kconfig, and the users using 
Couldn't we just remove kconfig and assume that all "people who already

know the kernel" anyway prefer to edit their .config using vi?  ;-)
In my experience, the vast majority of kconfig users are not the few

people working on distribution kernels, most of the kconfig userbase

could be better described by the use case "sysadmin who knows about the

hardware in his machine and which filesystems he uses".
And there must have been a reason why a leading kernel developer has

written a complete book covering only configuration and building of the

kernel - the target audience of this book are most likely not "people 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

The patch which is discussed here is specifically targeted towards users

who are convinced that they can migrate to different drivers without

reading Kconfig help texts.

--

Stefan Richter

-=====-=-=== =--= -===-

http://arcgraph.de/sr/

-

Nothing about the patch is only about migration.
The same applies if you configure a kernel from scratch.
Do "make menuconfig" with the .config you are normally using, count the

number of options that are visible, and ask yourself whether we can

really expect users to read the help texts for every single option shown.
People mostly read help texts for options where they don't understand

what this option is about - and "Serial ATA" therefore is an option that 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Hello,
On Fri, 14 Sep 2007 17:15:22 +0200
As a "make menuconfig" user, let me say that I agree. Of course, I'm used

to rebuild kernel, but sometimes, some options are not clear, and the help

text is searched for. But, getting too much of "No help text available"

usually results in people no more reading the help text.
What about splitting the screen to have the top half with the menu, and the

bottom half with the help ?
Paul
--

Paul Rolland                                E-Mail : rol(at)witbe.net

Witbe.net SA                                Tel. +33 (0)1 47 67 77 77

Les Collines de l'Arche                     Fax. +33 (0)1 47 67 77 99

F-92057 Paris La Defense                    RIPE : PR12-RIPE
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur

"Some people dream of success... while others wake up and work hard at it" 
"I worry about my child and the Internet all the time, even though she's too

young to have logged on yet. Here's what I worry about. I worry that 10 or 15

years from now, she will come to me and say 'Daddy, where were you when they

took freedom of the press away from the Internet?'"

--Mike Godwin, Electronic Frontier Foundation

-

I useually have more screen space available to the side then above and

below the list of options.
David Lang

-

I assert that a Kconfig prompt (a visible Kconfig variable) _without_

help text is a bug.

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

Hello Stefan,
On Sat, 15 Sep 2007 10:25:39 +0200
Here is an example from 2.6.34-rc6 :

 .config - Linux Kernel v2.6.23-rc6 Configuration

------------------------------------------------------------------------------

 +------------------------- Provide RTC interrupt -------------------------+

 | There is no help available for this kernel option.                      |

 | Symbol: HPET_EMULATE_RTC [=y]                                           |

 | Prompt: Provide RTC interrupt                                           |

 |   Defined at arch/x86_64/Kconfig:471                                    |

 |   Depends on: HPET_TIMER && RTC=y                                       |

 |   Location:                                                             |

 |   -> Processor type and features |   
Regards,

Paul

-

I take the liberty to modify the CC list.
The same prompt existed in arch/i386/Kconfig without help text too but

it was later made invisible and automatic by pre-2.6.13 patch "remove

special HPET_EMULATE_RTC config option", commit

c91096d85c95c6b7fe8d7065e2aa6825e0bdaca9: "We had a user whose apps

weren't working correctly because his "rtc" wasn't working fully.  For

the sake of simplicity, it seems sensible to always enable HPET RTC

emulation."
  - So, which criteria influence whether HPET_EMULATE_RTC should be

    enabled on x86_64 or not?
  - In case that there is no compelling reason to disable it if its

    dependencies are satisfied, shouldn't it rather be invisible and

    automatic like on i386?

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

It should be automatic. Please send a patch.
-Andi

-

I don't know exactly what this option does...

Andi says it should be automatic rather than exposed as a prompt.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---
--- linux.orig/arch/x86_64/Kconfig

+++ linux/arch/x86_64/Kconfig

@@ -469,8 +469,9 @@ config HPET_TIMER

 	  <http://www.intel.com/hardwaredesign/hpetspec.htm>.
 config HPET_EMULATE_RTC

-	bool "Provide RTC interrupt"

+	bool

 	depends on HPET_TIMER && RTC=y

+	default y
 # Mark as embedded because too many people got it wrong.

 # The code disables itself when not needed.
--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/
-

If you create .config from scratch, then you can get away without

reading help texts if you have a target with minimal hardware and

protocols requirements and you know all the subsystems involved.
In all other cases, you theoretically need to read all help texts (minus

the ones that don't appear because you deselect entire subsystems).  In

practice, this takes too much time, hence you take an existing .config

(yours or somebody else's) and go from there.
Whenever one enables an option for the first time, it would IMO be

foolish to ignore its help text.

--

Stefan Richter

-=====-=-=== =--= -===-

http://arcgraph.de/sr/

-

Kconfig let's you start with the defconfig when doing "make menuconfig"

without any .config present, so in practice users start from the

defconfig and then go through all menus at once enabling and disabling

options to adapt the configurations to their needs.
Or they start from the "includes everything" .config of their 
Then the number of non-foolish users is quite near to 0...
If you expect people to read several hundreds or thousands of help texts

only for configuring a kernel then you are expecting something that is

simply not realistic.
It is intuitive for a user to enable the "Serial ATA" menu and he might

not expect to have to read the help text when he has SATA drivers, while

having to enable anything in the "SCSI device support" menu is highly 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

[...]
Perhaps.  Although I meant only options which one enables oneself, not
It surely is unintuitive, and it is one of the worse cases where the

current menu layout is unintuitive.  We have to improve that, even

though it is ultimately impossible to serve everyone's needs equally

well or, generally, make kernel configuration a piece of cake.
Note though, some suggestions which came up here don't actually make the

menus more intuitive.  Notably the patch "Select BLK_DEV_SD for all

SCSI/libata drivers" is counterintuitive in a different color:  It

follows the philosophy of "I know what's good for you and I act on your

behalf behind your back --- trust me, it's for your best".
I too am guilty of proposing the usage of 'select'

(http://lkml.org/lkml/2007/9/8/9) but I suggested a variant which lets

the user stay informed and in control (as far as this is possible with

'select' which always increases complexity, never reduces it).
But rather than adding multiple menu items which enable the same option,

a reorganization of the menus which better reflect the role of SCSI core

and SCSI highlevel might be more effective --- similar to "Networking"

which is separate from "Network device support"

(http://lkml.org/lkml/2007/9/10/5, http://lkml.org/lkml/2007/9/10/115).

--

Stefan Richter

-=====-=-=== =--= -===-

http://arcgraph.de/sr/

-

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---
Applicable to 2.6.23-rc6 and to scsi-misc.
 drivers/scsi/Kconfig |   32 ++++++++++++++++++++------------

 1 file changed, 20 insertions(+), 12 deletions(-)
Index: linux-2.6.23-rc6/drivers/scsi/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig

+++ linux-2.6.23-rc6/drivers/scsi/Kconfig

@@ -12,23 +12,31 @@ config SCSI

 	depends on BLOCK

 	select SCSI_DMA if HAS_DMA

 	---help---

-	  If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or

-	  any other SCSI device under Linux, say Y and make sure that you know

-	  the name of your SCSI host adapter (the card inside your computer

-	  that "speaks" the SCSI protocol, also called SCSI controller),

-	  because you will be asked for it.

-

-	  You also need to say Y here if you have a device which speaks

-	  the SCSI protocol.  Examples of this include the parallel port

-	  version of the IOMEGA ZIP drive, USB storage devices, Fibre

-	  Channel, FireWire storage and the IDE-SCSI emulation driver.

+	  This option enables core support for SCSI protocols.

+	  You need it

+	  - for classic parallel SCSI hardware,

+	  - for newer SCSI transports such as Fibre Channel, FireWire storage,

+	    or iSCSI,

+	  - for non-SCSI hardware which speaks SCSI protocols, such as USB

+	    storage devices or the parallel port version of Iomega Zip drive,

+	  - for non-SCSI hardware whose drivers translate from and to SCSI

+	    protocols, like the IDE-SCSI emulation driver and most notably

+	    for all SATA drivers.
 	  To compile this driver as a module, choose M here and read

 	  <file:Documentation/scsi/scsi.txt>.

 	  The module will be called scsi_mod.
 	  However, do not compile this as a module if your root file system

-	  (the one containing the directory /) is located on a SCSI device.

+	  (the one containing the directory /) is located on a SCSI device

+	  or on a device whose...
[ message continues ]

You left out PATA running libata drivers.  Not just SATA is affected

there.  Looks pretty decent otherwise.
--

Len Sorensen

-

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

Subject: SCSI: update Kconfig help text to indicate SCSI core's widespread usage
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---

 drivers/scsi/Kconfig |   32 ++++++++++++++++++++------------

 1 file changed, 20 insertions(+), 12 deletions(-)
Index: linux-2.6.23-rc6/drivers/scsi/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig

+++ linux-2.6.23-rc6/drivers/scsi/Kconfig

@@ -12,23 +12,31 @@ config SCSI

 	depends on BLOCK

 	select SCSI_DMA if HAS_DMA

 	---help---

-	  If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or

-	  any other SCSI device under Linux, say Y and make sure that you know

-	  the name of your SCSI host adapter (the card inside your computer

-	  that "speaks" the SCSI protocol, also called SCSI controller),

-	  because you will be asked for it.

-

-	  You also need to say Y here if you have a device which speaks

-	  the SCSI protocol.  Examples of this include the parallel port

-	  version of the IOMEGA ZIP drive, USB storage devices, Fibre

-	  Channel, FireWire storage and the IDE-SCSI emulation driver.

+	  This option enables core support for SCSI protocols.

+	  You need it

+	  - for classic parallel SCSI hardware,

+	  - for newer SCSI transports such as Fibre Channel, FireWire storage,

+	    or iSCSI,

+	  - for non-SCSI hardware which speaks SCSI protocols, such as USB

+	    storage devices or the parallel port version of Iomega Zip drive,

+	  - for non-SCSI hardware whose drivers translate from and to SCSI

+	    protocols, most notably all Serial ATA drivers, and Parallel ATA

+	    via the ATA configuration option.
 	  To compile this driver as a module, choose M here and read

 	  <file:Documentation/scsi/scsi.txt>.

 	  The module will be called scsi_mod.
 	  However, do not compile this as a module if your root file system

-	  (the one containing the directory /) is located on ...
[ message continues ]

How about that one for libata driven PATA CDROM drives?  Could replace

SATA with libata, or something similar.
--

Len Sorensen

-

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

Subject: SCSI: update Kconfig help text to indicate SCSI core's widespread usage
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---

 drivers/scsi/Kconfig |   67 ++++++++++++++++++++++---------------------

 1 file changed, 35 insertions(+), 32 deletions(-)
Index: linux-2.6.23-rc6/drivers/scsi/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig

+++ linux-2.6.23-rc6/drivers/scsi/Kconfig

@@ -12,23 +12,31 @@ config SCSI

 	depends on BLOCK

 	select SCSI_DMA if HAS_DMA

 	---help---

-	  If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or

-	  any other SCSI device under Linux, say Y and make sure that you know

-	  the name of your SCSI host adapter (the card inside your computer

-	  that "speaks" the SCSI protocol, also called SCSI controller),

-	  because you will be asked for it.

-

-	  You also need to say Y here if you have a device which speaks

-	  the SCSI protocol.  Examples of this include the parallel port

-	  version of the IOMEGA ZIP drive, USB storage devices, Fibre

-	  Channel, FireWire storage and the IDE-SCSI emulation driver.

+	  This option enables core support for SCSI protocols.

+	  You need it

+	  - for classic parallel SCSI hardware,

+	  - for newer SCSI transports such as Fibre Channel, FireWire storage,

+	    or iSCSI,

+	  - for non-SCSI hardware which speaks SCSI protocols, such as USB

+	    storage devices or the parallel port version of Iomega Zip drive,

+	  - for non-SCSI hardware whose drivers translate from and to SCSI

+	    protocols, most notably all Serial ATA drivers, and Parallel ATA

+	    via the ATA configuration option.
 	  To compile this driver as a module, choose M here and read

 	  <file:Documentation/scsi/scsi.txt>.

 	  The module will be called scsi_mod.
 	  However, do not compile this as a module if your root file system

-	  (the one containing the directory /) is ...
[ message continues ]

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---
And one more update:

There is SAS too, and I forgot 'is' in "on a disk which __ accessed via".
 drivers/scsi/Kconfig |   67 ++++++++++++++++++++++---------------------

 1 file changed, 35 insertions(+), 32 deletions(-)
Index: linux-2.6.23-rc6/drivers/scsi/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig

+++ linux-2.6.23-rc6/drivers/scsi/Kconfig

@@ -12,23 +12,31 @@ config SCSI

 	depends on BLOCK

 	select SCSI_DMA if HAS_DMA

 	---help---

-	  If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or

-	  any other SCSI device under Linux, say Y and make sure that you know

-	  the name of your SCSI host adapter (the card inside your computer

-	  that "speaks" the SCSI protocol, also called SCSI controller),

-	  because you will be asked for it.

-

-	  You also need to say Y here if you have a device which speaks

-	  the SCSI protocol.  Examples of this include the parallel port

-	  version of the IOMEGA ZIP drive, USB storage devices, Fibre

-	  Channel, FireWire storage and the IDE-SCSI emulation driver.

+	  This option enables core support for SCSI protocols.

+	  You need it

+	  - for classic parallel SCSI hardware,

+	  - for newer SCSI transports such as Fibre Channel, FireWire storage,

+	    SAS, or iSCSI,

+	  - for non-SCSI hardware which speaks SCSI protocols, such as USB

+	    storage devices or the parallel port version of Iomega Zip drive,

+	  - for non-SCSI hardware whose drivers translate from and to SCSI

+	    protocols, most notably all Serial ATA drivers, and Parallel ATA

+	    via the ATA configuration option.
 	  To compile this driver as a module, choose M here and read

 	  <file:Documentation/scsi/scsi.txt>.

 	  The module will be called scsi_mod.
 	  However, do not compile this as a module if your root file system

-	  (the one containing the directory /) is located on a SCSI device.

+	  (the on...
[ message continues ]

You expect all kconfig users to read and completely understand this?
Although it's no longer required that the user sees the CONFIG_SCSI

option at all since we can determine automaically when it's required
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Well, one could add a
	You don't need it

	- for x,

	- for y.
bullet list.
I occasionally write documentation without the expectation that every
Maybe you can hide CONFIG_SCSI, but you still need to provide the above

information --- then under the sd, sr, st, sg options, which may

actually be the better places although it increases redundancy.

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

On Fri, 14 Sep 2007 23:14:21 +0200 (CEST)
There is SRP too.

-

I think I'll rewrite it as "for newer SCSI transports such as FireWire

storage."  ;-)
If SRP was in, can 'such as' be omitted?  "for newer SCSI transports

(Fibre Channel, FireWire storage, iSCSI, SAS, SRP),"  Or would be "for

newer SCSI transports such as Fibre Channel, FireWire storage, iSCSI,

SAS, and more," be OK?

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

On Sat, 15 Sep 2007 08:16:03 +0200
scsi-ml has SPI, FC, iSCSI, SAS, and SRP transport classes (SRP is in

scsi-misc now). It's a bit strange to omit only SRP, I think. But I

might be too SRP-biased.

-

"such as... and more" suggests that there are indeed more SCSI

transports supported by Linux than mentioned in this help text.
We could also write "such as Fibre Channel, iSCSI, SAS, and more," if

you suspect bias on my side. ;-)  Help texts should be concise.

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

On Sat, 15 Sep 2007 14:30:10 +0200
I think that you can remove "such as" if you add SRP and SSA. "for

SCSI transports such as Fibre Channel, FireWire, SAS, iSCSI, SRP, or

SSA" should be fine. But I'm not sure that scsi-ml has a SSA hba

-

Looks great.  I like it.
--

Len Sorensen

-

The SCSI core and SCSI high-level drivers play a central role not just

for the whole lot of different SCSI Architecture types of hardware and

protocols, but also for subsystems which drive non SCSI hardware,

especially libata.
Hence the options pertaining to SCSI core and high-level are separated

out into an own top-level menu outside the "Device Drivers" submenu, and

some prompts are reworded.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---
Applies after patch "SCSI: update Kconfig help text to indicate SCSI

core's widespread usage", http://lkml.org/lkml/2007/9/14/168.  These two

patches could very well be collapsed into one.
 arch/alpha/Kconfig            |    2

 arch/arm/Kconfig              |    2

 arch/avr32/Kconfig            |    2

 arch/blackfin/Kconfig         |    2

 arch/cris/Kconfig             |    2

 arch/frv/Kconfig              |    2

 arch/i386/Kconfig             |    2

 arch/ia64/Kconfig             |    2

 arch/m32r/Kconfig             |    2

 arch/m68k/Kconfig             |    2

 arch/m68knommu/Kconfig        |    2

 arch/mips/Kconfig             |    2

 arch/parisc/Kconfig           |    2

 arch/powerpc/Kconfig          |    2

 arch/ppc/Kconfig              |    2

 arch/s390/Kconfig             |    2

 arch/sh/Kconfig               |    2

 arch/sh64/Kconfig             |    2

 arch/sparc/Kconfig            |    2

 arch/sparc64/Kconfig          |    2

 arch/um/Kconfig               |    2

 arch/v850/Kconfig             |    2

 arch/x86_64/Kconfig           |    4

 arch/xtensa/Kconfig           |    2

 drivers/Kconfig               |    2

 drivers/scsi/Kconfig          | 1589 ----------------------------------

 drivers/scsi/Kconfig.lowlevel | 1578 +++++++++++++++++++++++++++++++++

 27 files changed, 1635 insertions(+), 1584 deletions(-)
Index: linux-2.6.23-rc6/arch/alpha/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/arch/alpha/Kconfig

+++ l...
[ message continues ]

Actually the addition "This menu also presents options for specific SCSI
(I'll gladly do that, or only send an update of the 'split Kconfig menu'

patch with that sentence backed out, if desired.)

--

Stefan Richter

-=====-=-=== =--= -===-

http://arcgraph.de/sr/
-

Date:

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

Subject: SCSI: split Kconfig menu into two
The SCSI core and SCSI high-level drivers play a central role not just

for the whole lot of different SCSI Architecture types of hardware and

protocols, but also for subsystems which drive non SCSI hardware,

especially libata.
Hence the options pertaining to SCSI core and high-level are separated

out into an own top-level menu outside the "Device Drivers" submenu, and

some prompts are reworded.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---
Update:  adjusted to "[PATCH update] SCSI: update Kconfig help text to

indicate SCSI core's widespread usage" from September 14, 23:14:21 +0200
 drivers/Kconfig               |    4

 drivers/scsi/Kconfig          | 1587 ----------------------------------

 drivers/scsi/Kconfig.lowlevel | 1578 +++++++++++++++++++++++++++++++++

 3 files changed, 1584 insertions(+), 1585 deletions(-)
Index: linux-2.6.23-rc6/drivers/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/Kconfig

+++ linux-2.6.23-rc6/drivers/Kconfig

@@ -1,5 +1,7 @@

 # drivers/Kconfig
+source "drivers/scsi/Kconfig"

+

 menu "Device Drivers"
 source "drivers/base/Kconfig"

@@ -22,7 +24,7 @@ source "drivers/misc/Kconfig"
 source "drivers/ide/Kconfig"
-source "drivers/scsi/Kconfig"

+source "drivers/scsi/Kconfig.lowlevel"
 source "drivers/ata/Kconfig"
Index: linux-2.6.23-rc6/drivers/scsi/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig

+++ linux-2.6.23-rc6/drivers/scsi/Kconfig

@@ -1,14 +1,7 @@

-menu "SCSI device support"

-

-config RAID_ATTRS

-	tristate "RAID Transport Class"

-	default n

-	depends on BLOCK

-	---help---

-	  Provides RAID

+menu "Storage (core and SCSI commands)"
 config SCSI

-	tristate "SCSI device support"

+	tristate "Storage support (core and SCSI commands)"

 	depends on BLOC...
[ message continues ]

Hi Stefan.
Such a patch really calls for some minimal unifacation among
Exactly the same change for all architectures.

IT would be good to introduce a common file that contains

some of the shared stuff from the different architectures.

We could start out simple with:
arch/Kconfig.arch:
source "net/Kconfig"

source "drivers/Kconfig"

source "fs/Kconfig"

source "security/Kconfig"

source "crypto/Kconfig"

source "lib/Kconfig"
And then source it in all relevant arch Kconfig files.

It is not all that can use it but most do.

A trivial task but one small step towards unification between

the architectures on the Kconfig level.
	Sam

-

cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

Subject: SCSI: split Kconfig menu into two
The SCSI core and SCSI high-level drivers play a central role not just

for the whole lot of different SCSI Architecture types of hardware and

protocols, but also for subsystems which drive non SCSI hardware,

especially libata.
Hence the options pertaining to SCSI core and high-level are separated

out into an own top-level menu outside the "Device Drivers" submenu, and

some prompts are reworded.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---

 drivers/Kconfig               |    4

 drivers/scsi/Kconfig          | 1589 ----------------------------------

 drivers/scsi/Kconfig.lowlevel | 1578 +++++++++++++++++++++++++++++++++

 3 files changed, 1588 insertions(+), 1583 deletions(-)
Index: linux-2.6.23-rc6/drivers/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/Kconfig

+++ linux-2.6.23-rc6/drivers/Kconfig

@@ -1,5 +1,7 @@

 # drivers/Kconfig
+source "drivers/scsi/Kconfig"

+

 menu "Device Drivers"
 source "drivers/base/Kconfig"

@@ -22,7 +24,7 @@ source "drivers/misc/Kconfig"
 source "drivers/ide/Kconfig"
-source "drivers/scsi/Kconfig"

+source "drivers/scsi/Kconfig.lowlevel"
 source "drivers/ata/Kconfig"
Index: linux-2.6.23-rc6/drivers/scsi/Kconfig

===================================================================

--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig

+++ linux-2.6.23-rc6/drivers/scsi/Kconfig

@@ -1,14 +1,7 @@

-menu "SCSI device support"

-

-config RAID_ATTRS

-	tristate "RAID Transport Class"

-	default n

-	depends on BLOCK

-	---help---

-	  Provides RAID

+menu "Storage (core and SCSI commands)"
 config SCSI

-	tristate "SCSI device support"

+	tristate "Storage support (core and SCSI commands)"

 	depends on BLOCK

 	select SCSI_DMA if HAS_DMA

 	---help---

@@ -42,13 +35,6 @@ config SCSI_DMA

 	bool

 	default n
-config SCSI_TGT

-	tristate "SCSI target sup...
[ message continues ]

Nearly right.  ;-)
This way the order is wrong:
There should first be the lowlevel SCSI, SATA, USB etc. drivers, these

drivers should select CONFIG_SCSI, and then the menu offering support 
What is "storage support"?

SATA?

PATA?

USB mass storage?

MMC?

MTD?
Whether or not a driver uses the SCSI layer is an implementation detail

(it even differs for the two USB mass storage implementations and the

two PATA implementations in the kernel) the user shouldn't have to know

about.
I don't see any reason why CONFIG_SCSI should have to stay user-visible 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Right, the patch is wrong for those architectures which include

drivers/scsi/Kconfig directly, rather than indirectly via drivers/Kconfig.
The order was inspired by
	# the protocols etc.

	"Networking"
	# the interconnects

	"Device Drivers"/ "Network device support"
So that order is wrong too?
However, there is also precedence for the order which you suggest:  The

partition and filesystems options come after device driver options.
Vice versa, I don't see any reason for "select SCSI" anywhere after my

patch.

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

SCSI is a generic peripheral bus (recall the expansion of the acronym).

Even though probably the most common, storage is one of its applications

only (think scanners for an immediately obvious other one).  I find

describing CONFIG_SCSI as "storage support" misleading and inappropriate.
 Referring to your example it is like calling generic networking (i.e.

CONFIG_NET) "Ethernet support".
  Maciej

-

The expansion of the acronym doesn't fit anymore to what SCSI is today,
Right.  I wrote that in lack of better words, but at least I added "SCSI

commands" in parentheses.  Something like "SCSI I/O - core and command

sets" would much better describe what it is, but it would put "SCSI"

first again and thus wouldn't reflect that  Linux' SCSI core and

highlevel is in broader use than just for actual SCSI hardware...  Of

course there is no way around the issue that Linux' SCSI core's and

highlevel's role cannot be characterized in 3...6 words only, but there
Wrong comparison.

--

Stefan Richter

-=====-=-=== =--= =---=

http://arcgraph.de/sr/

-

It's different since _all_ network device drivers require networking 
Different to CONFIG_SCSI, CONFIG_NET=n is so exotic that we should 
If users who don't need it now enable CONFIG_SCSI (and drivers/ide/

usage is not that uncommon) that's a regression in the user interface.
If the lowlevel SCSI drivers move into a separate menu as your patch

does, we simply no longer have any good reason for bothering the user 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Aha, first all interconnects/transports are configured.  If none of them

'select'ed SCSI, the menu for sd, sr, st stays invisible.  Otherwise it

is exposed.
It still doesn't entirely clarify whether users need sd, sr, st, and

whether thy need sd for the disk with root filesystem.

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

If you want to do it in a really perfect way, help texts aren't the

solution. You'll have to make the options like CONFIG_BLK_DEV_SR no

longer be user visible and select'ed through dummy options like e.g.:
config USB_STORAGE

        tristate "USB Mass Storage support"

        depends on USB

	select SCSI

	help

	  ...
config USB_STORAGE_SD

	tristate "USB Mass Storage hard disk support"

	depends on USB_STORAGE

	select BLK_DEV_SD

	help

	  ...
config USB_STORAGE_SR

        tristate "USB Mass Storage CD/DVD support"

        depends on USB_STORAGE

	select BLK_DEV_SR

        help
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

...
Perfect is in the eye of the beholder.  You would consequently have to

add such options into all menus which contain scsi low-level providers.
Also, one more question on whether CONFIG_SCSI ought to be 'select'ed:

Where do scsi-core options like CONFIG_SCSI_CONSTANTS go?

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

Kconfig is a user interface, so perfect is what is best for the
The first question is whether it's for actual SCSI hardware [1] or for

the block layer functionality which the SCSI subsystem has become.

The mixture of these two is the root of much user confusion.
With the help text "The error messages regarding your SCSI hardware will

be easier to understand if you say Y here" a user wouldn't have expected

to see you using it in a firewire driver. But unless I miss anything,

the setting of SCSI_SCAN_ASYNC does only affect "real" SCSI hardware.
If you check each option and place it either in the generic storage menu

or the SCSI lowlevel menu this would fix much possible user confusion.
But these are relatively unimportant options compared to e.g.

USB_STORAGE=y, BLK_DEV_SD=n, which is a misconfiguration many

users run into, so having one menu somewhere with these advanced 
cu

Adrian
[1] SCSI as in "sold as SCSI"
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Duplicate options with different names in different menus, but which all
FireWire hardware which implements SBP-2 is SCSI hardware...  But this
It affects every hardware which is driven by scsi low-level providers
True.
So,

    config SCSI_CONSTANTS

        "Kernel log messages from the SCSI subsystem will be easier to

        understand if you say Y here..."

would say what this option really does.  But to some degree the need to

explain what the SCSI subsystem or SCSI core is and which other

subsystems make use of it remains.  Maybe it's OK to provide
Difficult.  Does e.g. hardware sold as SAS count as "sold as SCSI"?  How

about SBP-2 then?  ;-)

--

Stefan Richter

-=====-=-=== =--= -====

http://arcgraph.de/sr/

-

Different to your approach of trying to achieve the same with one huge

help text I see a realistic chance of it working.
What's other alternatives do we have?
Automatically select BLK_DEV_SD and BLK_DEV_SR if one driver that uses 
This is a debug option and it's unlikely that users will need it unless

someone explicitely requested them to do so, so it's not such an 
If SBP-2 is what you get in a shop when asking for an external
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

I recognize it's a rhetorical question :)  The answer is of course "no".
I hope the other participants of this thread register the severe

disinclination of the maintainers to change this stuff, as this is a

classic case of making a mountain out of a molehill[1].
For the -vast majority- of people configuring the kernel, this is not a

problem.  Kernel people are -expected- to know what they're doing,

especially when switching from one major subsystem to another.
Therefore, all this is IMO wasted effort and hot air.  There are far

more important issues to deal with.
	Jeff
[1] http://www.bartleby.com/59/4/makeamountai.html

-

I doubt your claim is true since the vast majority of kconfig users

are most likely not kernel developers.
@Greg:

Do you have any numbers regarding how your "Linux Kernel in a Nutshell"

is selling?
It's not only about switching, the same problems awaits people when 
Why don't we dump kconfig and write the .config by hand?  ;-)
More seriously:

Yes, there are many other important issues in the kernel.

But not fixing kconfig UI problems doesn't fix these issues faster.
I have seen people running into problems because some required

option wasn't set - in the simplest cases things like IDE without DMA

because a help text wasn't updated when more hardware support was added

to a driver.
You might not care about the kconfig users.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

It is selling reasonably well for an O'Reilly book from what I have been
The downloads are spread around all of the kernel.org mirrors so I have

absolutely no idea what they are.
Nor do I really want to, as it doesn't matter to me.
thanks,
greg k-h

-

Agreed, and actually not fixing Kconfig UI problems will make the other

issues being fixed *slower* (because they result in *increased* workload
This is why nowadays IDE DMA support is automatically selected by IDE
...and even if their attempts/solutions may not be proper yet they should

not be discouraged to work on these problems...
Thanks,

Bart

-

Irrelevant in this case, because there is no increased workload on the 
Please don't take this any more off-topic than it already is.
IDE DMA option was vastly different.  The options in question here

affect whether or not you have a block device to use -- something that 
There is no problem, in this case.
Otherwise, there would be more than a complaint or two per year.
	Jeff
-

It has already been raised by making SATA configuration counterintuitive
OK, I'll stop here and I'll just patiently wait till the SATA Kconfig

issue comes up again on LKML (then I'll just smile and move on to
Thanks,

Bart

-

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

---
Applies after patch "SCSI: split Kconfig menu into two".

I didn't want to change whitespace in the portions that this patch

moved from drivers/scsi/Kconfig to drivers/scsi/Kconfig.lowlevel,

hence produced this follow-up.
 drivers/scsi/Kconfig.lowlevel |    8 ++++----

 1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.23-rc6/drivers/scsi/Kconfig.lowlevel

===================================================================

--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig.lowlevel

+++ linux-2.6.23-rc6/drivers/scsi/Kconfig.lowlevel

@@ -252,7 +252,7 @@ config SCSI_DPT_I2O

 	tristate "Adaptec I2O RAID support "

 	depends on !64BIT && SCSI && PCI && VIRT_TO_BUS

 	help

-	  This driver supports all of Adaptec's I2O based RAID controllers as

+	  This driver supports all of Adaptec's I2O based RAID controllers as

 	  well as the DPT SmartRaid V cards.  This is an Adaptec maintained

 	  driver by Deanna Bonds.  See <file:Documentation/scsi/dpti.txt>.
@@ -457,7 +457,7 @@ config SCSI_GDTH

 	---help---

 	  Formerly called GDT SCSI Disk Array Controller Support.
-	  This is a driver for RAID/SCSI Disk Array Controllers (EISA/ISA/PCI)

+	  This is a driver for RAID/SCSI Disk Array Controllers (EISA/ISA/PCI)

 	  manufactured by Intel Corporation/ICP vortex GmbH. It is documented

 	  in the kernel source in <file:drivers/scsi/gdth.c> and

 	  <file:drivers/scsi/gdth.h.>

@@ -491,7 +491,7 @@ config SCSI_GENERIC_NCR5380_MMIO

 	select SCSI_SPI_ATTRS

 	---help---

 	  This is a driver for the old NCR 53c80 series of SCSI controllers

-	  on boards using memory mapped I/O.

+	  on boards using memory mapped I/O.

 	  It is explained in section 3.8 of the SCSI-HOWTO, available from

 	  <http://www.tldp.org/docs.html#howto>.  If it doesn't work out

 	  of the box, you may have to change some settings in

@@ -1261,7 +1261,7 @@ config SCSI_DEBUG

 	  each with multiple ...
[ message continues ]

ACK
-

Disk support over SCSI/SATA is hardly an "optional extra". It's more the 99+%
When it costs 10000 people half an hour to learn and correct this it

wasted 5000 hours of previous livetime.
Besides there is no good reason to have ever learned this imho.
-Andi
-

^^^^^            ^       ^
Poor me. Here I am -- still waiting for my 15 minutes of fame in /this/ life...
;-)
bjd
-

Using that argument, there's an equal case for always requiring SCSI to

be built for every kernel, since very few people can boot a system

without a disk.  However, the 1% case is the embedded flash booting

community plus a few others, so we allow SCSI to be optional for our 1%

who don't want it.
At base, the Kconfig system is designed to give the greatest flexibility

with the fewest foot shooting opportunities.  However, we do tend to err

on the side of flexibility if there's a conflict between the two design
The process of becoming an expert in the kernel build system naturally

involves making mistakes and learning from them, so this is probably

time reasonably well spent.
James
-

Nevertheless we should try to arrange the menus in a way that makes

sense to as many people as possible.  The difficulty is, different

environments call for different menu layouts, as your previous example

of SATA DVD-only boxes demonstrates.
However, liberal usage of 'select' is not the ultimate solution to

create menus that work for more people.  Just one problem with select is

that it works behind the back of the people configuring kernels (unless

they use an UI with debug options turned on) --- they have less control,

they are less informed.  ATA already 'select's SCSI.  What do we gain

from hiding the fact that Linux' SCSI option is not just for those

50-wire ribbons (which people still think SCSI stands for) but is a very

central Linux subsystem for even more than what complies to the SCSI

family of standards?
'select' should really be limited to switch on small library-like code

without further dependencies or requirements.  SCSI, together with its

upper layer options, is not of this kind of library.
We should think about order and grouping of prompts and the labels of

prompts (there were already suggestions in this discussion) before we

resort to 'select' --- or even worse, select options unconditionally

which are not always necessary to be enabled.
A pro pos grouping of options --- consider how options for another

central subsystem are laid out:
	Networking

		Networking options

			...

			TCP/IP networking

			...

		...
	Device Drivers

		...

		Network device support

			...

			Ethernet (10 or 100MBit)

			...

		...
This also happens to reflect the layout of sources in directories, and

the current SCSI menu layout is close to source layout too --- but it

doesn't have to be that way.

--

Stefan Richter

-=====-=-=== =--= -=-=-

http://arcgraph.de/sr/

-

If someone's keen on really restructuring these things -- in this analogy:
Storage

	Storage Options

		...

		Disk

		Optical

		...

	...
Device Drivers

	...

	Storage Support

		...

		IDE

		PATA

		SATA

		SCSI

		USB

		FW

		...

	...
(sound is an example where both in the menus and the tree everything is kept

under one top-level sound/ directory, not sound/ and drivers/sound/ as for

networking -- opinions may vary which one's better I guess).
This is just config menus -- on a source code level, it would also make

sense at least at some point to introduce "storage/" alongside net/ and

sound/ and move things around I guess.
Rene.
-

I'd say that someone needs to use a vendor kernel, or at least
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

Vendor kernels tend to compile forever and require initrds. For

just testing a kernel quickly compiling only a few drivers in

is much more convenient.
Also when you've been using CONFIG_IDE before it is not completely

obvious you need BLK_SD for your hard disk.
-Andi

-

Switching to different drivers without reading the help text?

Tough.

--

Stefan Richter

-=====-=-=== =--= -=---

http://arcgraph.de/sr/

-

The individual driver descriptions don't say BLK_SD needs to be selected.
Besides if all descriptions said that the computer could as well

do it for the user automatically. After all it's a stupid repetive

task and computers are much better at those than humans.
-Andi

-

In your patch, it is not the computer who finds out that the user wants

BLK_SD.  It is you who predetermined that the user wants it.

--

Stefan Richter

-=====-=-=== =--= -=---

http://arcgraph.de/sr/

-

That's not entirely fair ... if you're switching over from a config

you've been dragging around for years which uses IDE rather than ATA,

it's far from obvious which config options you need to change.  I think

Andi's patch is a good one.  It might also be good to select SR (at

least my wife's laptop has the cd-rom on SATA).
--

Intel are signing my paycheques ... these opinions are still mine

"Bill, look, we understand that you're interested in selling us this

operating system, but compare it to ours.  We can't possibly take such

a retrograde step."

-

I know that it's difficult to get people to read docs & help text,

and maybe it is needed in more places, but CONFIG_ATA (SATA/PATA)

help text says:
  NOTE: ATA enables basic SCSI support; *however*,

  'SCSI disk support', 'SCSI tape support', or

  'SCSI CDROM support' may also be needed,

  depending on your hardware configuration.
A popup makes some sense, but I don't know if menuconfig knows how to

do popup warnings... and it needs to be done for all *configs,

not just menuconfig.
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

A popup hardly ever makes sense - popups generally are a

bad user interface. The user will have to dismiss the popup -

every time - whether he needs the warning or not.
But feel free to print a warning somewhere, such as a

status line. The warning itself is useful, but not something

we will have to dismiss in order to go on with the job.
Helge Hafting
-

Could one duplicate the configure options for scsi disk/tape/cdrom at

that place? The text should then probably read SCSI/SATA disk support

in both places.
MfG

        Goswin

-

Or rather than duplicating the menu items for the same options, split

the SCSI high-level options out into a top-level menu and adjust the

wording of the prompts.  http://lkml.org/lkml/2007/9/14/217
(top level)

menu "Storage (core and SCSI commands)"

	config SCSI

		tristate "Storage support (core and SCSI commands)"

	config BLK_DEV_SD

		tristate "Harddisks and other Direct access devices"

	config CHR_DEV_ST

		tristate "Tape drives"

	config CHR_DEV_OSST

		tristate "SCSI OnStream SC-x0 tape support"

	config BLK_DEV_SR

		tristate "CD-ROMs, DVD-ROMs"

	...
menu "Device Drivers"

	...

	menu "SCSI device support"

		config RAID_ATTRS

		config SCSI_TGT

		menu "SCSI Transports"

			...

		menuconfig SCSI_LOWLEVEL

			bool "SCSI low-level drivers"

			...
--

Stefan Richter

-=====-=-=== =--= -===-

http://arcgraph.de/sr/

-

For menuconfig I would much rather see that it had an additional

window at the bottom displaying the help text for the active menu line.
Implementing support for a pop-up in the kconfig language seems to be a bit

off the purpose of the kconfig language.
	Sam

-

Yes but that would mean that you have to open the help for each item
Maybe add a new type?
Folkert van Heusden
--

MultiTail na wan makriki wrokosani fu tan luku den logfile nanga san

den commando spiti puru. Piki puru spesrutu sani, wroko nanga difreti

kroru, tja kon makandra, nanga wan lo moro.

http://www.vanheusden.com/multitail/

----------------------------------------------------------------------

Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

-

How about
comment "Note: 'SCSI disk support' is required for SATA/PATA HDDs!"

	depends on ATA && !BLK_DEV_SD
--

Stefan Richter

-=====-=-=== =--= --===

http://arcgraph.de/sr/

-

Yes! Maybe create some status-line at the bottom of the screen in which

these hints scrollby. Like powertop does.
Folkert van Heusden
--

MultiTail är en flexibel redskap för att fälja logfilar, utför av

commandoer, filtrera, ge färg, sammanfoga, o.s.v. följa.

http://www.vanheusden.com/multitail/

----------------------------------------------------------------------

Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

-

(added Cc linux-ide)
'comment' is already supported by make {menu,x,g}config and AFAIK by

make oldconfig too.  It is not effective in make oldconfig though

because it will scroll off the screen quickly.
I am not a friend of 'select', but maybe the following actually helps.

I didn't follow all of this and previous related discussions, so I guess

somebody else suggested something like this before:
# drivers/ata/Kconfig
config ATA

	[...]
comment "Controller drivers"
[...low-level drivers go here...]
comment "Storage device drivers"
config ATA_SD

	tristate "SATA/PATA HDD support (via SCSI disk support)"

	depends on ATA

	select BLK_DEV_SD

	help

	  'SCSI disk support' is required to access SATA HDDs.  It is

	  also necessary for parallel ATA (IDE) HDDs if you use the

	  experimental parallel ATA option.
	  You can say Y or M here to select SCSI disk support, or you

	  can do so in the 'SCSI device support' section.
[...ditto for CD/DVD-ROMs, tapes, and generic support...]

--

Stefan Richter

-=====-=-=== =--= -=---

http://arcgraph.de/sr/

-

The problem with 'select' here is that it will enable BLK_DEV_SD,

but if SCSI is not enabled, it will not become enabled -- i.e.,

select does not follow the dependency chain.  So usually the
--

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

...
I checked the dependencies.  ATA depends on SCSI (actually, selects

SCSI), so all is well.  Otherwise I would have added more dependencies

to ATA_SD.

--

Stefan Richter

-=====-=-=== =--= -=---

http://arcgraph.de/sr/

-

Ah, that's good, then.  Thanks.
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

Not completely though.  Whenever a 'select' is inserted into the

dependency graph, the whole thing becomes more fragile WRT future changes.

--

Stefan Richter

-=====-=-=== =--= -=---

http://arcgraph.de/sr/

-

And what uses ATA_SD, or is the user supposed to manually enable it?
	Jan

--

-

It is merely there to produce the prompt which people asked for.

CONFIG_ATA_SD (or CONFIG_ATA_BLK_DEV_SD or whatever) won't turn up in

any Makefile or source code.
Note, I'm not fond of 'select' nor of dummy Kconfig variables.  Plus I

can personally live very well with the current solution (sd_mod et al

are mentioned in the help text at CONFIG_ATA).  That's why I posted only

the example instead of a complete patch.

--

Stefan Richter

-=====-=-=== =--= -=---

http://arcgraph.de/sr/

-

Having no sd support is perfectly valid. Imagine a diskless boot

with only sr support.

-

Ok, but that's not the most common situaties. What I'm suggesting is a

warning or a please note popup. Not neccessarily an error or refusing to

continue thing.
Folkert van Heusden
--

www.vanheusden.com/multitail - win een vlaai van multivlaai! zorg

ervoor dat multitail opgenomen wordt in Fedora Core, AIX, Solaris of

HP/UX en win een vlaai naar keuze

----------------------------------------------------------------------

Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

-

What IMHO makes sense is changing all references to SCSI CDROM,

SCSI DISK etc. to just CDROM, DISK, and changing SCSI (menu) to

something like MASS STORAGE.

--

Krzysztof Halasa

-

There is still too much SCSI in it IMO :-)

-

And to explain that point: SCSI device name inquiry is limited to 16 bytes.

That may be a limitation of SCSI (as in: the protocol), but the SCSI

*subsystem* should not impose such a tight limit.
	Jan

--

-