Re: why does x86 "make defconfig" build a single, lonely module?

["Satyam Sharma" <satyam.sharma@gmail.com>]

On 5/14/07, James Bottomley <James.Bottomley@steeleye.com> 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@gmail.com>
> >
> > ---
> >
> >  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