Bug 9769 - CONFIG_SCSI_WAIT_SCAN configure error
Summary: CONFIG_SCSI_WAIT_SCAN configure error
Status: RESOLVED DUPLICATE of bug 8763
Alias: None
Product: SCSI Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: scsi_drivers-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-17 04:47 UTC by Barry Kauler
Modified: 2009-06-17 10:21 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.24-rc8
Tree: Mainline
Regression: No


Attachments

Description Barry Kauler 2008-01-17 04:47:04 UTC
Latest working kernel version:
Earliest failing kernel version:
Distribution:
Hardware Environment:
Software Environment:
Problem Description:
There seems to be a bug when I run 'make menuconfig'. In the '.config'
file I always get this:

# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

The second line should not be there if the first is not set.

I tried by starting with a .config file that has that second line
removed, but after 'make menuconfig' it came back.

The 'scsi_wait_scan.ko' module is not needed if the first line is not
set, so why is the module being built? What purpose does it perform?
Isn't it a contradiction to have this situation?

Regards,
Barry Kauler
www.puppylinux.com
Comment 1 Natalie Protasevich 2008-02-07 23:28:59 UTC
This appears to be a dependency, but these are not dependent defines. CONFIG_SCSI_SCAN_ASYNC defines the default scan type, which can be overridden by the module parameter.
Comment 2 Anonymous Emailer 2008-02-08 07:01:54 UTC
Reply-To: James.Bottomley@HansenPartnership.com

On Thu, 2008-02-07 at 23:28 -0800, bugme-daemon@bugzilla.kernel.org
wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9769
> 
> 
> protasnb@gmail.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |protasnb@gmail.com,
>                    |                            |jejb@hansenpartnership.com
> 
> 
> 
> 
> ------- Comment #1 from protasnb@gmail.com  2008-02-07 23:28 -------
> This appears to be a dependency, but these are not dependent defines.
> CONFIG_SCSI_SCAN_ASYNC defines the default scan type, which can be overridden
> by the module parameter.

Yes, this is exactly right.  CONFIG_SCSI_ASYNC_SCAN doesn't affect the
code (async scan is always included) it affects the boot default.  In
either case, with the correct kernel parameters, you can boot either
sync or async scanning.

James
Comment 3 Natalie Protasevich 2008-02-08 07:56:22 UTC
Thanks, closing the bug.
Comment 4 Barry Kauler 2008-02-18 05:16:23 UTC
This is NOT an invalid bug!

In all previous kernels, if
# CONFIG_SCSI_SCAN_ASYNC is not set

then
CONFIG_SCSI_WAIT_SCAN=m
does not even appear in the .config file, and the module
scsi_wait_scan.ko is not built.
The module is NOT built, only in 2.6.24 is it getting built
regardless.

For 2.6.23.x and all earlier kernels, the module is not
built. 

Ditto when doing 'make menuconfig', in all previous kernels,
if CONFIG_SCSI_SCAN_ASYNC is turned off then the option to build
the module is not even offered. However in 2.6.24 it continues
to be offered regardless.

So, I repeat, this is a BUG!

Or, if you have made a change that requires the module to
be built regardless, can you please explain why it is needed
in the case of '.CONFIG_SCSI_SCAN_ASYNC is not set' and why
this change from all previous kernels.

Barry Kauler
Comment 5 Matthew Wilcox 2008-02-18 06:19:50 UTC
Sorry, it is an invalid bug.  This has been discussed a few times on linux-scsi.  If you have any SCSI driver built as a module, you (or the distro you are running) may need it.  We can't tell in Kconfig -- and you might choose to build another driver as a module later.  Or out of tree.

If you're sure you don't need it, then don't run 'make modules_install'.  It's about 2500 bytes ... why waste so much energy being angry?
Comment 6 Stefan Richter 2009-06-17 10:21:20 UTC
> why waste so much energy being angry?

The waste and anger is because the implementation is so strange, compared to how kernel modules are normally used, and because it is unexplained except in list archives.
Comment 7 Stefan Richter 2009-06-17 10:21:35 UTC

*** This bug has been marked as a duplicate of bug 8763 ***

Note You need to log in before you can comment on or make changes to this bug.