scsi_wait_scan: no option appears when configuring for scsi_wait_scan.
PATCH 1/1 scsi_wait_scan: no option appears when configuring for scsi_wait_scan.
FIXBUG: missing comment after tristate leads to no option for scsci_wait_scan when configuring.
When build kernel, this module is always built if I choose SCSI, and I can't find any option in the configuration menu, so I can't disable it or build it into kernel statically. After diving into the kernel source code, I found no comment after keyword tristate, then I added the comment and help.
----
Kconfig | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
scsi/Kconfig renamed from scsi/Kconfig.orig +6 -1
@@ -259,10 +259,15 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "Wait until all the async scans are complete" default m depends on SCSI depends on MODULES + help + Wait until all the async scans are complete. The idea is to use it in + initrd/initramfs scripts. You modprobe it after all the modprobes of + the root SCSI drivers and it will wait until they have all finished + scanning their busses before allowing the boot to proceed menu "SCSI Transports" depends on SCSI
Quoted 2 lines · Changli Gao
FIXBUG: missing comment after tristate leads to no option for
scsci_wait_scanwhen configuring.
Please search the archives. Patches along these lines have been rejected before.
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "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."
PATCH 1/1 SCSI: explain the hidden scsi_wait_scan Kconfig variable
People keep sending patches to expose CONFIG_SCSI_WAIT_SCAN as a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to this obscure and strange installed module and its Kconfig option.
--- drivers/scsi/Kconfig | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
drivers/scsi/Kconfig +16 -1
@@ -259,10 +259,25 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate # No prompt here, this is a hidden option. default m depends on SCSI depends on MODULES + help + Wait until all the async scans are complete. The idea is to use + it in initrd/ initramfs scripts. You modprobe it after all the + modprobes of the root SCSI drivers and it will wait until they + have all finished scanning their buses before allowing the boot + to proceed. + + Of course this does not work if targets boot independently of and + in parallel with the initiator, and/ or with transports with non- + deterministic target discovery schemes, and/ or if a transport + driver does not support scsi_wait_scan. + + Still, this option is not exposed as a prompt because little is + to be gained by disabling it, whereas people who accidentally + switch it off may wonder why their mkinitrd gets into trouble. menu "SCSI Transports" depends on SCSI
Signature · 3 lines
Stefan Richter -=====-==--= -==- =---= http://arcgraph.de/sr/
Re: [PATCH] SCSI: explain the hidden scsi_wait_scan Kconfig variable
Quoted 4 lines · Stefan Richter
People keep sending patches to expose
CONFIG_SCSI_WAIT_SCANas a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to this obscure and strange installed module and itsKconfigoption.
PS, references:
http://bugzilla.kernel.org/show_bug.cgi?id=8763
http://bugzilla.kernel.org/show_bug.cgi?id=8872
http://bugzilla.kernel.org/show_bug.cgi?id=9769
and more mailinglist references than you can shake a stick at, yet nobody is aware of.
Signature · 3 lines
Stefan Richter -=====-==--= -==- =---= http://arcgraph.de/sr/
Re: [PATCH] SCSI: explain the hidden scsi_wait_scan Kconfig variable
In reply to Stefan RichterQuoted 4 lines · Stefan Richter
People keep sending patches to expose
CONFIG_SCSI_WAIT_SCANas a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to this obscure and strange installed module and itsKconfigoption.
Aha, I really like this, and think it works. :)
Signature · 2 lines
Regards， Changli Gao([email protected])
James Bottomley
maintainerRe: [PATCH] SCSI: explain the hidden scsi_wait_scan Kconfig variable
In reply to Stefan RichterQuoted 15 lines · Stefan Richter
People keep sending patches to expose
CONFIG_SCSI_WAIT_SCANas a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to this obscure and strange installed module and itsKconfigoption.Signed-off-by Stefan Richter <[email protected]>--- drivers/scsi/Kconfig | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)Index: b/drivers/scsi/Kconfig
===================================================================
drivers/scsi/Kconfig config SCSI_SCAN_ASYNC · line 262
Quoted 5 lines
drivers/scsi/Kconfig +1
-1@@ -259,10 +259,25 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate # No prompt here, this is a hidden option.
Adding comments explaining this is good, I think.
Quoted 8 lines
drivers/scsi/Kconfig +5
-0default m depends on SCSI depends on MODULES + help + Wait until all the async scans are complete. The idea is to use + it in initrd/ initramfs scripts. You modprobe it after all the + modprobes of the root SCSI drivers and it will wait until they + have all finished scanning their buses before allowing the boot
drivers/scsi/Kconfig config SCSI_SCAN_ASYNC · line 280
Quoted 10 lines
drivers/scsi/Kconfig +10
-0+ to proceed. + + Of course this does not work if targets boot independently of and + in parallel with the initiator, and/ or with transports with non- + deterministic target discovery schemes, and/ or if a transport + driver does not support scsi_wait_scan. + + Still, this option is not exposed as a prompt because little is + to be gained by disabling it, whereas people who accidentally + switch it off may wonder why their mkinitrd gets into trouble.
But not a help text that can never be shown. Turn this into a comment and I'll apply the patch.
The reason is the fact that this could be construed as a detectable bug (option with help that can never be displayed) and someone with too much time on their hands someday might make a static checker for it.
James
Re: [PATCH] SCSI: explain the hidden scsi_wait_scan Kconfig variable
Quoted 46 lines · James Bottomley
Quoted 15 lines · Stefan Richter
People keep sending patches to expose
CONFIG_SCSI_WAIT_SCANas a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to this obscure and strange installed module and itsKconfigoption.Signed-off-by Stefan Richter <[email protected]>--- drivers/scsi/Kconfig | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)Index: b/drivers/scsi/Kconfig
===================================================================drivers/scsi/Kconfig config SCSI_SCAN_ASYNC · line 262
Quoted 5 lines
drivers/scsi/Kconfig +1
-1@@ -259,10 +259,25 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate # No prompt here, this is a hidden option.Adding comments explaining this is good, I think.
Quoted 8 lines
drivers/scsi/Kconfig +5
-0default m depends on SCSI depends on MODULES + help + Wait until all the async scans are complete. The idea is to use + it in initrd/ initramfs scripts. You modprobe it after all the + modprobes of the root SCSI drivers and it will wait until they + have all finished scanning their buses before allowing the bootdrivers/scsi/Kconfig config SCSI_SCAN_ASYNC · line 280
Quoted 10 lines
drivers/scsi/Kconfig +10
-0+ to proceed. + + Of course this does not work if targets boot independently of and + in parallel with the initiator, and/ or with transports with non- + deterministic target discovery schemes, and/ or if a transport + driver does not support scsi_wait_scan. + + Still, this option is not exposed as a prompt because little is + to be gained by disabling it, whereas people who accidentally + switch it off may wonder why their mkinitrd gets into trouble.But not a help text that can never be shown. Turn this into a comment and I'll apply the patch.
Quoted 3 lines
The reason is the fact that this could be construed as a detectable bug (option with help that can never be displayed) and someone with too much time on their hands someday might make a static checker for it.
In another thread we discussed that the help text should be visible when searching for an invisible symbol.
There are arguments both ways.
Personally I like the help syntax that we one day can benefit from and would not accept a warning for help text on symbols with no prompt.
Sam
PATCH 1/1 SCSI: explain the hidden scsi_wait_scan Kconfig variable
People keep sending patches to expose CONFIG_SCSI_WAIT_SCAN as a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to the unconditionally installed module and its Kconfig symbol.
---
update 1: more precise wording
update 2: same as comment instead of help (pick what you like better)
drivers/scsi/Kconfig | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/scsi/Kconfig +12 -1
@@ -259,10 +259,21 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate # No prompt here, this is an invisible symbol. default m depends on SCSI depends on MODULES +# scsi_wait_scan is a loadable module which waits until all the async scans are +# complete. The idea is to use it in initrd/ initramfs scripts. You modprobe +# it after all the modprobes of the root SCSI drivers and it will wait until +# they have all finished scanning their buses before allowing the boot to +# proceed. (This method is not applicable if targets boot independently in +# parallel with the initiator, or with transports with non-deterministic target +# discovery schemes, or if a transport driver does not support scsi_wait_scan.) +# +# This symbol is not exposed as a prompt because little is to be gained by +# disabling it, whereas people who accidentally switch it off may wonder why +# their mkinitrd gets into trouble. menu "SCSI Transports" depends on SCSI
Signature · 3 lines
Stefan Richter -=====-==--= -==- =--=- http://arcgraph.de/sr/
Re: [PATCH update 2] SCSI: explain the hidden scsi_wait_scan Kconfig variable
Quoted 4 lines · On Thu, 18 Jun 2009 21:03:23 +0200 (CEST) Stefan Richter…
People keep sending patches to expose
CONFIG_SCSI_WAIT_SCANas a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to the unconditionally installed module and itsKconfigsymbol.
How about the other possibility. People keepmaking it tunable because it makes sense for it to be tunable. Far better IMHO to make it tunable "if EMBEDDED"
Re: [PATCH update 2] SCSI: explain the hidden scsi_wait_scan Kconfig variable
Quoted 11 lines · Alan Cox
Quoted 4 lines · On Thu, 18 Jun 2009 21:03:23 +0200 (CEST) Stefan Richter…
People keep sending patches to expose
CONFIG_SCSI_WAIT_SCANas a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to the unconditionally installed module and itsKconfigsymbol.How about the other possibility. People keepmaking it tunable because it makes sense for it to be tunable. Far better IMHO to make it tunable "if EMBEDDED"
It doesn't make sense for it to be tunable.
All it does is control whether or not scsi_wait_scan.ko is built. Everyone who's complained about it has been of the form "I turned off all modules, but this module gets built anyway". For them, the answer is simple: Don't run "make modules_install".
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "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."
PATCH 1/1 SCSI: explain the hidden scsi_wait_scan Kconfig variable
In reply to Sam RavnborgPeople keep sending patches to expose CONFIG_SCSI_WAIT_SCAN as a tunable item. These patches aren't accepted upstream, so let's stop the ongoing irritation of people due to the unconditionally installed module and its Kconfig symbol.
---
update 1: more precise wording
drivers/scsi/Kconfig | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
drivers/scsi/Kconfig +14 -1
@@ -259,10 +259,23 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate # No prompt here, this is an invisible symbol. default m depends on SCSI depends on MODULES + help + Wait until all the async scans are complete. The idea is to use + it in initrd/ initramfs scripts. You modprobe it after all the + modprobes of the root SCSI drivers and it will wait until they + have all finished scanning their buses before allowing the boot + to proceed. (This method is not applicable if targets boot + independently in parallel with the initiator, or with transports + with non-deterministic target discovery schemes, or if a transport + driver does not support scsi_wait_scan.) + + This symbol is not exposed as a prompt because little is to be + gained by disabling it, whereas people who accidentally switch it + off may wonder why their mkinitrd gets into trouble. menu "SCSI Transports" depends on SCSI
Signature · 3 lines
Stefan Richter -=====-==--= -==- =--=- http://arcgraph.de/sr/