This patch adds a proper help for SCSI_WAIT_SCAN and allows the module to be
deselected. I see no reason to force it being build. It also makes it
impossible to compile-in the module.
Signed-off-by: Bernhard Walle <[email protected]>
---
drivers/scsi/Kconfig | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 403ecad..42b8355 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -257,10 +257,15 @@ config SCSI_SCAN_ASYNC
or async on the kernel's command line.
config SCSI_WAIT_SCAN
- tristate
+ tristate "Module to wait until all the async scans are complete"
default m
- depends on SCSI
- depends on MODULES
+ depends on SCSI && m
+ help
+ This is a simple module to 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
--
1.6.0.2
So I'm not the only one :-)
Please see this thread:
http://lkml.org/lkml/2008/10/22/355
On Thu, Nov 13, 2008 at 3:11 PM, Bernhard Walle <[email protected]> wrote:
> This patch adds a proper help for SCSI_WAIT_SCAN and allows the module to be
> deselected. I see no reason to force it being build. It also makes it
> impossible to compile-in the module.
>
>
> Signed-off-by: Bernhard Walle <[email protected]>
> ---
> drivers/scsi/Kconfig | 11 ++++++++---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 403ecad..42b8355 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -257,10 +257,15 @@ config SCSI_SCAN_ASYNC
> or async on the kernel's command line.
>
> config SCSI_WAIT_SCAN
> - tristate
> + tristate "Module to wait until all the async scans are complete"
> default m
> - depends on SCSI
> - depends on MODULES
> + depends on SCSI && m
> + help
> + This is a simple module to 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
> --
> 1.6.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Fabio Comolli wrote:
> So I'm not the only one :-)
> Please see this thread:
>
> http://lkml.org/lkml/2008/10/22/355
See also:
http://marc.info/?l=linux-scsi&m=122538386519971&w=2
http://marc.info/?l=linux-scsi&m=122539443509753&w=2
BR,
Dmitri
On Thu, November 13, 2008 14:22, Dmitri Vorobiev wrote:
> Fabio Comolli wrote:
>> So I'm not the only one :-)
>> Please see this thread:
>>
>> http://lkml.org/lkml/2008/10/22/355
>
> See also:
>
> http://marc.info/?l=linux-scsi&m=122538386519971&w=2
> http://marc.info/?l=linux-scsi&m=122539443509753&w=2
I suggest reading http://lkml.org/lkml/2007/5/13/75.
Basically, if you want to get rid of it you need to provide
a viable alternative. (Loading a module is not the right
way to call a kernel function...) Then it could be default
'n' and marked as deprecated.
--
Simon Arlott
Simon Arlott wrote:
> On Thu, November 13, 2008 14:22, Dmitri Vorobiev wrote:
>> Fabio Comolli wrote:
>>> So I'm not the only one :-)
>>> Please see this thread:
>>>
>>> http://lkml.org/lkml/2008/10/22/355
>> See also:
>>
>> http://marc.info/?l=linux-scsi&m=122538386519971&w=2
>> http://marc.info/?l=linux-scsi&m=122539443509753&w=2
>
> I suggest reading http://lkml.org/lkml/2007/5/13/75.
>
> Basically, if you want to get rid of it you need to provide
> a viable alternative.
Blocking read on a character device or a /proc file? A new system call (this is a bit overkill, of course, but strictly speaking it _is_ an alternative)?
Dmitri
>