(adding Cc: LSML and author) On 10/22/2008, Fabio Comolli wrote at LKML: > Hi. > In kernel 2.6.27.2 - drivers/scsi/Kconfig we have: > > config SCSI_WAIT_SCAN > tristate > default m > depends on SCSI > depends on MODULES > > The tristate field is empty. This has the effect that this option is > not visible in menuconfig and so it's always selected. The default is > "m" for all architectures and so this module is always compiled if > SCSI and MODULES are both enabled. > > I'm using a patch like this one: > > config SCSI_WAIT_SCAN > - tristate > + tristate "Wait until all the async scans are complete" > default m > depends on SCSI > depends on MODULES > > to get rid of that module. > > Of course, I have no idea if this is correct or the current behavior > is the expected one. > > Regards, > Fabio What's the correct behaviour is contentious. There have been complaints that it shouldn't be built if it is not needed. However, how it currently works is how those who added and merged that feature thought that it should be. Notes on your suggestion: - If you make it a visible prompt, you should also add a help text. No Kconfig prompts without good help text, please! - The suggested prompt text doesn't describe the matter too well. scsi_wait_scan rather is a module which userland can use to get a signal for when scans (by some but not all transports) are done. (The signal is the end of module initialization of the scsi_wait_scan module.) I.e. the kernel as a whole doesn't necessarily wait, just this module does. You could use the comment in drivers/scsi/scsi_wait_scan.c and the changelog of http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3e082a910d217b2e7b186077ebf5a1126a68c62f as a basis for the Kconfig help text. You could actually add a help text even to invisible prompts, just for documentation purposes. -- Stefan Richter -=====-==--- =-=- =-==- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html