unnecessary SCSI module
PATCH 1/1 unnecessary SCSI module
When configuring MODULES with the kernel to be able to load external drivers coming as modules, but not using anything as module in the kernel itself, one would expect to end up in a module-free kernel. Currently, you don't if you use SCSI. You'll get one unnecessary module.
Please consider the attached patch.
drivers/scsi/Kconfig renamed from drivers/scsi/Kconfig.orig +1 -1
@@ -259,7 +259,7 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate default m - depends on SCSI + depends on SCSI = m || SCSI_SCAN_ASYNC = y depends on MODULES menu "SCSI Transports"
James Bottomley
maintainerQuoted 12 lines · Ingo Brueckl
When configuring MODULES with the kernel to be able to load external drivers coming as modules, but not using anything as module in the kernel itself, one would expect to end up in a module-free kernel. Currently, you don't if you use SCSI. You'll get one unnecessary module.
Please consider the attached patch.
Signed-off-by Ingo Brueckl <[email protected]>
drivers/scsi/Kconfig config SCSI_SCAN_ASYNC · line 262
Quoted 5 lines
drivers/scsi/Kconfig renamed from drivers/scsi/Kconfig.orig +1
-1@@ -259,7 +259,7 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate default m - depends on SCSI + depends on SCSI = m || SCSI_SCAN_ASYNC = y
This isn't right because SCSI_SCAN_ASYNC only sets the *default* behaviour of the kernel. Even if it's n the user can still boot up with async scans by setting the kernel parameter.
It also keeps coming up regularly:
http://marc.info/?t=122658550300002
James
PATCH 1/1 unnecessary SCSI module
Quoted 8 lines · James Bottomley
Quoted 4 lines
When configuring MODULES with the kernel to be able to load external drivers coming as modules, but not using anything as module in the kernel itself, one would expect to end up in a module-free kernel. Currently, you don't if you use SCSI. You'll get one unnecessary module.
This isn't right because
SCSI_SCAN_ASYNConly sets the *default* behaviour of the kernel. Even if it's n the user can still boot up with async scans by setting the kernel parameter.
Ok, understood. But has it to be a module then? Why not giving the choice between building it directly into the kernel or as a module?
Quoted 1 line
It also keeps coming up regularly:
Well, then something doesn't seem to be ok, does it? ;-)
Ingo
drivers/scsi/Kconfig renamed from drivers/scsi/Kconfig.orig +6 -2
@@ -257,10 +257,14 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate - default m + tristate "SCSI wait scanning" depends on SCSI depends on MODULES + help + If you are using a SCSI module and do asynchronous SCSI scanning + (either by having selected SCSI_SCAN_ASYNC or by specifying + "scsi_mod.scan=async" on the kernel's command line), you MUST say Y + here. menu "SCSI Transports" depends on SCSI
James Bottomley
maintainerQuoted 7 lines · Ingo Brueckl
Quoted 4 lines · James Bottomley
Quoted 4 lines
When configuring MODULES with the kernel to be able to load external drivers coming as modules, but not using anything as module in the kernel itself, one would expect to end up in a module-free kernel. Currently, you don't if you use SCSI. You'll get one unnecessary module.
Quoted 6 lines
Quoted 3 lines
This isn't right because
SCSI_SCAN_ASYNConly sets the *default* behaviour of the kernel. Even if it's n the user can still boot up with async scans by setting the kernel parameter.Ok, understood. But has it to be a module then? Why not giving the choice between building it directly into the kernel or as a module?
If you read through the threads, that question is answered.
Quoted 3 lines
Quoted 1 line
It also keeps coming up regularly:
Well, then something doesn't seem to be ok, does it? ;-)
James
Quoted 10 lines · James Bottomley
Quoted 9 lines · Ingo Brueckl
When configuring MODULES with the kernel to be able to load external drivers coming as modules, but not using anything as module in the kernel itself, one would expect to end up in a module-free kernel. Currently, you don't if you use SCSI. You'll get one unnecessary module.
Please consider the attached patch.
Signed-off-by Ingo Brueckl <[email protected]>
Quoted 12 lines
drivers/scsi/Kconfig config SCSI_SCAN_ASYNC · line 262
Quoted 8 lines
drivers/scsi/Kconfig renamed from drivers/scsi/Kconfig.orig +1
-1@@ -259,7 +259,7 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate default m - depends on SCSI + depends on SCSI = m || SCSI_SCAN_ASYNC = yThis isn't right because
SCSI_SCAN_ASYNConly sets the *default* behaviour of the kernel. Even if it's n the user can still boot up with async scans by setting the kernel parameter.
Indeed. Also, the issue is not with /how/ SCSI_WAIT_SCAN is switched on, it is perhaps with /that/ SCSI_WAIT_SCAN is switched on.
SCSI_WAIT_SCAN is a Kconfig variable which does not have a prompt --- like a large number of other Kconfig variables. Like most of these other hidden Kconfig variables, SCSI_WAIT_SCAN controls a very compact part of kernel functionality. Its only difference to most if not all of these variables is that it is a tristate variable which controls building of a .ko.
Quoted 5 lines
It also keeps coming up regularly:
http://marc.info/?t=122658550300002
James
And it will keep coming up because the reasons for these choices (default to m instead of n, no prompt) are not at all obvious. Perhaps you should add a comment to drivers/scsi/Kconfig.
Actually while I superficially searched the archive right now I did not find the reason for not prompting for this variable, other than "it doesn't hurt to build this module". Could be that there is an assumption that people who want the wait scan module in their initrd were unable to find a respective Kconfig prompt.
Signature · 3 lines
Stefan Richter -=====-==--= --== -=-=- http://arcgraph.de/sr/