On 5/14/07, James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote:
On Mon, 2007-05-14 at 17:53 +0530, Satyam Sharma wrote: > > I guess this is probably the behaviour that James wanted originally? No ... you're still not reading the explanation in the thread: The wait scan module is designed to wait for scans of driver modules. Whether SCSI=y or m has no effect on this ... you can still have modular drivers with built in SCSI.
Ah, I see why we _want_ this built as a _module_ only, and don't even want to expose the Kconfig option to the user, lest he screw himself later. But dangling "default m"'s or "default y"'s not exposed to the user do stand out discomfortingly in Kconfigs, wish there was a better way to handle this.
> > Anyway, attached patch (subsumes previous one) cleans up all this. > > Now, scsi_wait_scan is the only guy who controls waiting upon async > > scans to complete: > > > > If SCSI=n, SCSI_WAIT_SCAN=n, obviously. > > > > If SCSI=y, SCSI_WAIT_SCAN=y, so it gets built-in and is run at > > late_initcall. > > > > If SCSI=m, SCSI_WAIT_SCAN=m too and would hopefully be run > > by the initrd/initramfs scripts to wait for async SCSI bus scans to > > finish before allowing the boot to proceed. > > > > [ Attached patch does _not_ expose SCSI_WAIT_SCAN to the > > user at kernel configuration time, so if somebody wants it to be > > built as a module even when SCSI=y (why would anybody > > want that, doesn't make much sense to me to modprobe > > scsi_wait_scan _after_ boot-up), it would not be possible to > > do so. But if someone really wants that, let me know, we can > > add a depends, tristate "..." and help in this Kconfig option to > > accomplish that too. ] > > This has sadly become a one-person thread, but Robert informs > me in private mail that we can further clean/simplify the patch: > > [subsumes both previous patches] > > Signed-off-by: Satyam Sharma <satyam.sharma@xxxxxxxxx> > > --- > > drivers/scsi/Kconfig | 3 +-- > drivers/scsi/scsi_scan.c | 5 +---- > 2 files changed, 2 insertions(+), 6 deletions(-) > > --- > > diff -ruNp a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > --- a/drivers/scsi/Kconfig 2007-05-10 23:19:32.000000000 +0530 > +++ b/drivers/scsi/Kconfig 2007-05-14 17:59:51.000000000 +0530 > @@ -243,9 +243,8 @@ config SCSI_SCAN_ASYNC > > config SCSI_WAIT_SCAN > tristate > - default m > depends on SCSI > - depends on MODULES > + default SCSI > > menu "SCSI Transports" > depends on SCSI > diff -ruNp a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c > --- a/drivers/scsi/scsi_scan.c 2007-05-14 16:06:43.000000000 +0530 > +++ b/drivers/scsi/scsi_scan.c 2007-05-14 16:10:34.000000000 +0530 > @@ -184,14 +184,11 @@ int scsi_complete_async_scans(void) > /* Only exported for the benefit of scsi_wait_scan */ > EXPORT_SYMBOL_GPL(scsi_complete_async_scans); > > -#ifndef MODULE > /* > * For async scanning we need to wait for all the scans to complete before > * trying to mount the root fs. Otherwise non-modular drivers may not be ready > - * yet. > + * yet. This is done by scsi_wait_scan. > */ > -late_initcall(scsi_complete_async_scans); > -#endif This is actually not in mainline. It's an incorrect patch in -mm. The problem with late_initcall is that they queue in link order ... so any SCSI module (and there a few) linked after this won't benefit from it. The obvious hack is to have a separate file with this in the final link. However, Matthew Wilcox thinks he can do better.
Yeah, thanks for this explanation. -mm is probably what confused me here. I did consider the fact that late_initcall's are called in link order, but saw that there was an explicit effort (hack?) in drivers/scsi/Makefile to keep scsi_wait_scan last so that SCSI devices probe earlier ... not that this helps us with modular drivers, of course. Thanks, Satyam - 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
