Re: why does x86 "make defconfig" build a single, lonely module?
On Tue, May 15, 2007 01:41, Satyam Sharma wrote: > On 5/14/07, James Bottomley <[EMAIL PROTECTED]> 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. I've already suggested a sysfs attribute - or something equivalent - would be much better. It's just one function that a user might want to run multiple times (e.g. after adding scsi devices?) - why should loading a module be used for this? -- Simon Arlott - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On 5/14/07, James Bottomley <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > --- > > 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/Kconfig2007-05-10 23:19:32.0 +0530 > +++ b/drivers/scsi/Kconfig2007-05-14 17:59:51.0 +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.c2007-05-14 16:06:43.0 +0530 > +++ b/drivers/scsi/scsi_scan.c2007-05-14 16:10:34.0 +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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On May 14 2007 19:46, Alan Cox wrote: >> On May 13 2007 12:48, James Bottomley wrote: >> > >> >> Why does ATA select SCSI anyway? Surely PATA doesn't require it? >> >That's a bit offtopic and to the wrong list. >> >libata-pata does require SCSI ... >> >> And in the long run, that SCSI parts which are actually used by ATA >> should be factored out so that SCSI really is SCSI again, and not >> "Common layer for SCSI, SATA and PATA" or so. > >The common layer for the queueing is one thing, but the ATAPI devices >(CD-ROM etc) are SCSI commands over an ATA bus. A subset of SCSI commands >badly over an ATA bus but SCSI commands nevertheless - so they have the >same basic dependancies as USB storage does. Hm yes of course, but harddisks themselves do not normally need ATAPI; so it would be cool to be capable of throwing it out for PATA-and-no-CDROM boxes. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Mon, 14 May 2007 19:29:12 +0200 (MEST) Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On May 13 2007 12:48, James Bottomley wrote: > > > >> Why does ATA select SCSI anyway? Surely PATA doesn't require it? > > > >That's a bit offtopic and to the wrong list. > > > >libata-pata does require SCSI ... > > And in the long run, that SCSI parts which are actually used by ATA > should be factored out so that SCSI really is SCSI again, and not > "Common layer for SCSI, SATA and PATA" or so. The common layer for the queueing is one thing, but the ATAPI devices (CD-ROM etc) are SCSI commands over an ATA bus. A subset of SCSI commands badly over an ATA bus but SCSI commands nevertheless - so they have the same basic dependancies as USB storage does. Alan - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On May 13 2007 12:48, James Bottomley wrote: > >> Why does ATA select SCSI anyway? Surely PATA doesn't require it? > >That's a bit offtopic and to the wrong list. > >libata-pata does require SCSI ... And in the long run, that SCSI parts which are actually used by ATA should be factored out so that SCSI really is SCSI again, and not "Common layer for SCSI, SATA and PATA" or so. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
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. > > 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 <[EMAIL PROTECTED]> > > --- > > 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/Kconfig2007-05-10 23:19:32.0 +0530 > +++ b/drivers/scsi/Kconfig2007-05-14 17:59:51.0 +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.c2007-05-14 16:06:43.0 +0530 > +++ b/drivers/scsi/scsi_scan.c2007-05-14 16:10:34.0 +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. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
Hello, > > [...] > > config SCSI_WAIT_SCAN > > tristate > > - default m > > - depends on SCSI > > - depends on MODULES > > + default m if SCSI=m > > + default n > > Note that this also means SCSI_WAIT_SCAN=n (will not get compiled > and built even as a module) if SCSI=y. But this is perfectly fine, because > I see: > > #ifndef MODULE > late_initcall(scsi_complete_async_scans); > #endif > > in drivers/scsi/scsi_scan.c anyway, so the async scans will be waited > upon and get complete even when SCSI=y and scsi_scan_type=async, > i.e. you don't really need the scsi_wait_scan module in that case anyway. It seems there is a: late_initcall(wait_scan_init); in drivers/scsi/scsi_wait_scan.c too. So we can get rid of the redundant: #ifndef MODULE late_initcal(scsi_complete_async_scans); #endif in drivers/scsi/scsi_scan.c by enforcing SCSI_WAIT_SCAN=y when SCSI=y (and =m when SCSI=m). I guess this is probably the behaviour that James wanted originally? 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 <[EMAIL PROTECTED]> --- 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.0 +0530 +++ b/drivers/scsi/Kconfig 2007-05-14 17:59:51.0 +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.0 +0530 +++ b/drivers/scsi/scsi_scan.c 2007-05-14 16:10:34.0 +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 /** * scsi_unlock_floptical - unlock device via a special MODE SENSE command - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
Hello, > [...] > config SCSI_WAIT_SCAN > tristate > - default m > - depends on SCSI > - depends on MODULES > + default m if SCSI=m > + default n Note that this also means SCSI_WAIT_SCAN=n (will not get compiled and built even as a module) if SCSI=y. But this is perfectly fine, because I see: #ifndef MODULE late_initcall(scsi_complete_async_scans); #endif in drivers/scsi/scsi_scan.c anyway, so the async scans will be waited upon and get complete even when SCSI=y and scsi_scan_type=async, i.e. you don't really need the scsi_wait_scan module in that case anyway. It seems there is a: late_initcall(wait_scan_init); in drivers/scsi/scsi_wait_scan.c too. So we can get rid of the redundant: #ifndef MODULE late_initcal(scsi_complete_async_scans); #endif in drivers/scsi/scsi_scan.c by enforcing SCSI_WAIT_SCAN=y when SCSI=y (and =m when SCSI=m). I guess this is probably the behaviour that James wanted originally? 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. ] Thanks, Satyam Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> --- drivers/scsi/Kconfig |5 +++-- drivers/scsi/scsi_scan.c |5 + 2 files changed, 4 insertions(+), 6 deletions(-) --- diff -ruNp a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig --- a/drivers/scsi/Kconfig 2007-05-10 23:19:32.0 +0530 +++ b/drivers/scsi/Kconfig 2007-05-14 17:37:27.0 +0530 @@ -243,9 +243,10 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate - default m depends on SCSI - depends on MODULES + default y if SCSI=y + default m if SCSI=m + default n 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.0 +0530 +++ b/drivers/scsi/scsi_scan.c 2007-05-14 16:10:34.0 +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 /** * scsi_unlock_floptical - unlock device via a special MODE SENSE command - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On 5/14/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: [...] config SCSI_WAIT_SCAN tristate - default m - depends on SCSI - depends on MODULES + default m if SCSI=m + default n Note that this also means SCSI_WAIT_SCAN=n (will not get compiled and built even as a module) if SCSI=y. But this is perfectly fine, because I see: #ifndef MODULE late_initcall(scsi_complete_async_scans); #endif in drivers/scsi/scsi_scan.c anyway, so the async scans will be waited upon and get complete even when SCSI=y and scsi_scan_type=async, i.e. you don't really need the scsi_wait_scan module in that case anyway. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
Hi, On 5/13/07, James Bottomley <[EMAIL PROTECTED]> wrote: On Sun, 2007-05-13 at 11:10 -0500, James Bottomley wrote: > > - depends on SCSI > > + depends on SCSI_SCAN_ASYNC This is incorrect, alright, but not because of any of the reasons James mentions below. The only reason why some module (or Kconfig option) should _depend_ on some other Kconfig option is if (*and only if*) it re-uses _code_ exported by said dependency. In this particular case, SCSI_SCAN_ASYNC=y/n only controls the default value of some variable somewhere in SCSI, so no other code can meaningfully "depend" on it. > No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the > wait scan to be built in, which isn't the idea at all. Umm, this isn't true, actually. Plus SCSI_SCAN_ASYNC only sets the *default* for async scanning. You can alter this at boot time, so you could need the wait scan module even with it set to N. I think the _correct_ way to handle this situation (and which would make everyone happy here; Robert can get his module-free builds with defconfig, James gets his SCSI_WAIT_SCAN module even if nobody asked for it explicitly) would be as follows: --- Clean up Kconfig entry for CONFIG_SCSI_WAIT_SCAN. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> --- drivers/scsi/Kconfig |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- diff -ruNp a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig --- a/drivers/scsi/Kconfig 2007-05-10 23:19:32.0 +0530 +++ b/drivers/scsi/Kconfig 2007-05-14 15:12:46.0 +0530 @@ -243,9 +243,8 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate - default m - depends on SCSI - depends on MODULES + default m if SCSI=m + default n menu "SCSI Transports" depends on SCSI - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On 13/05/07 17:10, James Bottomley wrote:
On Sun, 2007-05-13 at 12:06 -0400, Dave Jones wrote:
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index e62d23f..0f6c370 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC
config SCSI_WAIT_SCAN
tristate
default m
- depends on SCSI
+ depends on SCSI_SCAN_ASYNC
No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the
wait scan to be built in, which isn't the idea at all.
Try it. It doesn't force it to be built in.
Plus SCSI_SCAN_ASYNC only sets the *default* for async scanning. You
can alter this at boot time, so you could need the wait scan module even
with it set to N.
static int __init wait_scan_init(void)
{
scsi_complete_async_scans();
return 0;
}
Could that not be built-in to SCSI as a sysfs attribute, rather than using
a module to tell the kernel to do something? It looks like someone might
want to call scsi_complete_async_scans() more than once too - if they also
don't allow modules to be unloaded then they can't.
--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, 2007-05-13 at 19:26 +0100, Simon Arlott wrote:
> On 13/05/07 18:48, James Bottomley wrote:
> > On Sun, 2007-05-13 at 18:42 +0100, Simon Arlott wrote:
> >>> If you set CONFIG_MODULE=y and build SCSI we assume you could have a
> >>> SCSI driver module at some point, which would necessitate the wait scan
> >>> module.
> >> This should be implemented like "Library routines" and only added if such
> >> a SCSI driver module is actually selected. Why can't it at least be a
> >> visible option in the menu? (Although even then it looks like it's
> >> impossible to disable).
> >
> > There's out of tree modules to consider.
>
> Ok, I propose we make dozens of modules default 'm' in case an out of
> tree module requires it.
>
> SCSI_SCAN_ASYNC ("Asynchronous SCSI scanning"): "You can load the
> scsi_wait_scan module to ensure that all scans have completed."
>
> It looks like SCSI_WAIT_SCAN is pointless unless SCSI_SCAN_ASYNC
> is selected - so it should depend on it:
Why don't you just actually read the thread? Then you'd understand why
this isn't correct.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, May 13, 2007 at 07:26:31PM +0100, Simon Arlott wrote: > It looks like SCSI_WAIT_SCAN is pointless unless SCSI_SCAN_ASYNC > is selected - so it should depend on it: > > --- > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > index e62d23f..0f6c370 100644 > --- a/drivers/scsi/Kconfig > +++ b/drivers/scsi/Kconfig > @@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC > config SCSI_WAIT_SCAN > tristate > default m > -depends on SCSI > +depends on SCSI_SCAN_ASYNC > depends on MODULES > > menu "SCSI Transports" This is the same broken patch that I posted earlier in this thread. See James' follow-ups to my mail. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On 13/05/07 18:48, James Bottomley wrote:
On Sun, 2007-05-13 at 18:42 +0100, Simon Arlott wrote:
If you set CONFIG_MODULE=y and build SCSI we assume you could have a
SCSI driver module at some point, which would necessitate the wait scan
module.
This should be implemented like "Library routines" and only added if such
a SCSI driver module is actually selected. Why can't it at least be a
visible option in the menu? (Although even then it looks like it's
impossible to disable).
There's out of tree modules to consider.
Ok, I propose we make dozens of modules default 'm' in case an out of
tree module requires it.
SCSI_SCAN_ASYNC ("Asynchronous SCSI scanning"): "You can load the
scsi_wait_scan module to ensure that all scans have completed."
It looks like SCSI_WAIT_SCAN is pointless unless SCSI_SCAN_ASYNC
is selected - so it should depend on it:
---
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index e62d23f..0f6c370 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC
config SCSI_WAIT_SCAN
tristate
default m
- depends on SCSI
+ depends on SCSI_SCAN_ASYNC
depends on MODULES
menu "SCSI Transports"
--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, 2007-05-13 at 18:42 +0100, Simon Arlott wrote: > > If you set CONFIG_MODULE=y and build SCSI we assume you could have a > > SCSI driver module at some point, which would necessitate the wait scan > > module. > > This should be implemented like "Library routines" and only added if such > a SCSI driver module is actually selected. Why can't it at least be a > visible option in the menu? (Although even then it looks like it's > impossible to disable). There's out of tree modules to consider. > Why does ATA select SCSI anyway? Surely PATA doesn't require it? That's a bit offtopic and to the wrong list. libata-pata does require SCSI ... and I suspect the libata developers didn't want to trip users by them having to select SCSI before they could select libata. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On 13/05/07 17:27, James Bottomley wrote: On Sun, 2007-05-13 at 12:20 -0400, Robert P. J. Day wrote: since this thread looks like it's going to get away from me in a hurry :-), my only point in asking was to point out that that lone module was the only thing preventing the build from being module-free. i'm not saying that that's *necessarily* a good thing, but it just strikes me as odd that, out of all of the possible modules that might be selected in a default config for x86, this was the *only* one that was picked. i just think it's a bit weird, that's all. It's designed on the predicate that people who want to be module free will actually set CONFIG_MODULE=n. If you set CONFIG_MODULE=y and build SCSI we assume you could have a SCSI driver module at some point, which would necessitate the wait scan module. This should be implemented like "Library routines" and only added if such a SCSI driver module is actually selected. Why can't it at least be a visible option in the menu? (Although even then it looks like it's impossible to disable). Why does ATA select SCSI anyway? Surely PATA doesn't require it? -- Simon Arlott - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, 13 May 2007, James Bottomley wrote: > On Sun, 2007-05-13 at 12:20 -0400, Robert P. J. Day wrote: > > since this thread looks like it's going to get away from me in a > > hurry :-), my only point in asking was to point out that that lone > > module was the only thing preventing the build from being module-free. > > > > i'm not saying that that's *necessarily* a good thing, but it just > > strikes me as odd that, out of all of the possible modules that might > > be selected in a default config for x86, this was the *only* one that > > was picked. > > > > i just think it's a bit weird, that's all. > > It's designed on the predicate that people who want to be module free > will actually set CONFIG_MODULE=n. > > If you set CONFIG_MODULE=y and build SCSI we assume you could have a > SCSI driver module at some point, which would necessitate the wait scan > module. ok, fair enough. thanks. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, May 13, 2007 at 11:10:55AM -0500, James Bottomley wrote: > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > > index e62d23f..0f6c370 100644 > > --- a/drivers/scsi/Kconfig > > +++ b/drivers/scsi/Kconfig > > @@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC > > config SCSI_WAIT_SCAN > >tristate > >default m > > - depends on SCSI > > + depends on SCSI_SCAN_ASYNC > > No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the > wait scan to be built in, which isn't the idea at all. hmm? with my change... $ make defconfig $ grep SCSI_SCAN_ASYNC .config # CONFIG_SCSI_SCAN_ASYNC is not set $ grep SCSI_WAIT_SCAN .config $ make oldconfig $ grep SCSI_SCAN_ASYNC .config CONFIG_SCSI_SCAN_ASYNC=y $ grep SCSI_WAIT_SCAN .config CONFIG_SCSI_WAIT_SCAN=m Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, May 13, 2007 at 11:18:35AM -0500, James Bottomley wrote: > On Sun, 2007-05-13 at 11:10 -0500, James Bottomley wrote: > > > -depends on SCSI > > > +depends on SCSI_SCAN_ASYNC > > > > No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the > > wait scan to be built in, which isn't the idea at all. > > Plus SCSI_SCAN_ASYNC only sets the *default* for async scanning. You > can alter this at boot time, so you could need the wait scan module even > with it set to N. Ah, good point. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, 2007-05-13 at 12:20 -0400, Robert P. J. Day wrote: > since this thread looks like it's going to get away from me in a > hurry :-), my only point in asking was to point out that that lone > module was the only thing preventing the build from being module-free. > > i'm not saying that that's *necessarily* a good thing, but it just > strikes me as odd that, out of all of the possible modules that might > be selected in a default config for x86, this was the *only* one that > was picked. > > i just think it's a bit weird, that's all. It's designed on the predicate that people who want to be module free will actually set CONFIG_MODULE=n. If you set CONFIG_MODULE=y and build SCSI we assume you could have a SCSI driver module at some point, which would necessitate the wait scan module. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, 13 May 2007, James Bottomley wrote: > On Sun, 2007-05-13 at 12:06 -0400, Dave Jones wrote: > > On Sun, May 13, 2007 at 11:22:55AM -0400, Robert P. J. Day wrote: > > > > > > not a big deal, but is there a reason that a "make defconfig" on my > > > x86 system ends up selecting and building a single module? > > > > > > Building modules, stage 2. > > > MODPOST 1 modules > > > CC drivers/scsi/scsi_wait_scan.mod.o > > > LD [M] drivers/scsi/scsi_wait_scan.ko > > > > > > is there something special about that module? just curious. > > > > My guess is that someone was paranoid and wanted not to have > > to answer a zillion "my machine won't boot any more" questions > > when async scsi scanning was added. > > This might further clarify.. > > > > --- > > > > The scsi_wait_scan module is only really useful if async scanning > > is enabled. > > > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > > index e62d23f..0f6c370 100644 > > --- a/drivers/scsi/Kconfig > > +++ b/drivers/scsi/Kconfig > > @@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC > > config SCSI_WAIT_SCAN > > tristate > > default m > > - depends on SCSI > > + depends on SCSI_SCAN_ASYNC > > No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force > the wait scan to be built in, which isn't the idea at all. since this thread looks like it's going to get away from me in a hurry :-), my only point in asking was to point out that that lone module was the only thing preventing the build from being module-free. i'm not saying that that's *necessarily* a good thing, but it just strikes me as odd that, out of all of the possible modules that might be selected in a default config for x86, this was the *only* one that was picked. i just think it's a bit weird, that's all. rday p.s. it's mostly a case of -- whenever i notice something being done only *once* in the entire source tree, i'm always a bit leery. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, 2007-05-13 at 11:10 -0500, James Bottomley wrote: > > - depends on SCSI > > + depends on SCSI_SCAN_ASYNC > > No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the > wait scan to be built in, which isn't the idea at all. Plus SCSI_SCAN_ASYNC only sets the *default* for async scanning. You can alter this at boot time, so you could need the wait scan module even with it set to N. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, 2007-05-13 at 12:06 -0400, Dave Jones wrote: > On Sun, May 13, 2007 at 11:22:55AM -0400, Robert P. J. Day wrote: > > > > not a big deal, but is there a reason that a "make defconfig" on my > > x86 system ends up selecting and building a single module? > > > > Building modules, stage 2. > > MODPOST 1 modules > > CC drivers/scsi/scsi_wait_scan.mod.o > > LD [M] drivers/scsi/scsi_wait_scan.ko > > > > is there something special about that module? just curious. > > My guess is that someone was paranoid and wanted not to have > to answer a zillion "my machine won't boot any more" questions > when async scsi scanning was added. > This might further clarify.. > > --- > > The scsi_wait_scan module is only really useful if async scanning > is enabled. > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > index e62d23f..0f6c370 100644 > --- a/drivers/scsi/Kconfig > +++ b/drivers/scsi/Kconfig > @@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC > config SCSI_WAIT_SCAN > tristate > default m > - depends on SCSI > + depends on SCSI_SCAN_ASYNC No. SCSI_SCAN_ASYNC is a bool ... if you depend on it, you'll force the wait scan to be built in, which isn't the idea at all. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why does x86 "make defconfig" build a single, lonely module?
On Sun, May 13, 2007 at 11:22:55AM -0400, Robert P. J. Day wrote: > > not a big deal, but is there a reason that a "make defconfig" on my > x86 system ends up selecting and building a single module? > > Building modules, stage 2. > MODPOST 1 modules > CC drivers/scsi/scsi_wait_scan.mod.o > LD [M] drivers/scsi/scsi_wait_scan.ko > > is there something special about that module? just curious. My guess is that someone was paranoid and wanted not to have to answer a zillion "my machine won't boot any more" questions when async scsi scanning was added. This might further clarify.. --- The scsi_wait_scan module is only really useful if async scanning is enabled. Signed-off-by: Dave Jones <[EMAIL PROTECTED]> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index e62d23f..0f6c370 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -244,7 +244,7 @@ config SCSI_SCAN_ASYNC config SCSI_WAIT_SCAN tristate default m - depends on SCSI + depends on SCSI_SCAN_ASYNC depends on MODULES menu "SCSI Transports" -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
