Kconfig bug
PATCH 1/1 Kconfig bug
Hi all,
I noticed I had a module option being built that wasn't in menuconfig.
It is missing description. I also added a brief help message.
Signed off by: Nick Warne <[email protected]>
Nick
Signature · 1 line
Free Software Foundation Associate Member 5508
drivers/scsi/Kconfig renamed from drivers/scsi/Kconfig_old +8 -1
@@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "Wait for SCSI scan completion" default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu "SCSI Transports" depends on SCSI
tristate and bool not enogh for Kconfig anymore
I think there is a need for Kconfig to specify that a functionality could be built as a module or not built at all.
Some drivers require that firmware is loaded when the driver is initialized. The kernel has functionalities for this by using a userspace program. However, this userspace program is only usable from modules and not during boot while any initrd or any other file system has not yet been mounted and yet less any processes started.
For example, Slackware 12 has a huge kernel with a lot of drivers for different file systems and scsi cards built in. This kernel is supposed to be a non optimized kernel that works on almost any machine even without an initrd. In that kernel CONFIG_SCSI_QLA_FC is set to y but still it is not possible to boot from any of those cards as the driver requires a firmware file. Even together with an initrd image containing the firmware file it is still not possible to use the driver as the driver require the firmware file before any processes has been started from the initrd image.
For such drivers requiring firmware files, or if there is any other reason that the driver doesn't work when built into the kernel it would be useful with another choice than bool or tristate.
Best regards Henrik
Signature · 3 lines
NOTE: Dear Outlook users: Please remove me from your address books.
Read this article and you know why:
http://newsforge.com/article.pl?sid=03/08/21/143258Re: tristate and bool not enogh for Kconfig anymore
Quoted 2 lines · Henrik Carlqvist
I think there is a need for
Kconfigto specify that a functionality could be built as a module or not built at all.
I assume
depends on MODULES
should do the trick.
Sam
Re: tristate and bool not enogh for Kconfig anymore
Quoted 8 lines · On Sat, 20 Oct 2007 21:17:00 +0200 Sam Ravnborg wrote:
Quoted 2 lines · Henrik Carlqvist
I think there is a need for
Kconfigto specify that a functionality could be built as a module or not built at all.I assume
depends on MODULESshould do the trick.
Some modules use (e.g.)
depends on PCMCIA and m
but using MODULES does make more sense to me.
---
~Randy
Re: tristate and bool not enogh for Kconfig anymore
In reply to Sam RavnborgQuoted 8 lines · Sam Ravnborg
Quoted 2 lines · Henrik Carlqvist
I think there is a need for
Kconfigto specify that a functionality could be built as a module or not built at all.I assume
depends on MODULESshould do the trick.
Umm... I think that will work backwards, and give you CONFIG_FOO=y if.f the kernel *supports* modules. What he needs is to be able to say CONFIG_FOO=n or CONFIG_FOO=m, but *ban* CONFIG_FOO=y.
(At least, in my kernel, I have MODULES=y, and several other things from init/Kconfig have 'depends on MODULES' and also end up 'y':
% zgrep MODULE /proc/config.gzCONFIG_MODULES=yCONFIG_MODULE_UNLOAD=yCONFIG_MODULE_FORCE_UNLOAD=yCONFIG_MODULE_SRCVERSION_ALL=yCONFIG_MODULE_VERIFY_ELF=y
Re: tristate and bool not enogh for Kconfig anymore
Quoted 9 lines · On Sun, 21 Oct 2007 00:47:38 -0400 [email protected] wrote:
Quoted 4 lines · Sam Ravnborg
I assume
depends on MODULESshould do the trick.
Umm... I think that will work backwards, and give you
CONFIG_FOO=yif.f the kernel *supports* modules. What he needs is to be able to sayCONFIG_FOO=norCONFIG_FOO=m, but *ban*CONFIG_FOO=y.
Yes, thats right, MODULES does not ban y as would be needed. As an example I tried to do a quick test, I edited drivers/scsi/qla2xxx/Kconfig to look like this:
-8<------------------------------------------------------- config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support" depends on PCI && SCSI && MODULES
select SCSI_FC_ATTRS
select FW_LOADER
---help---
This qla2xxx driver supports all QLogic Fibre Channel PCI and PCIe host adapters.
By default, firmware for the ISP parts will be loaded via the Firmware Loader interface.
ISP Firmware Filename
---------- -----------------
21xx ql2100_fw.bin
22xx ql2200_fw.bin
2300, 2312, 6312 ql2300_fw.bin
2322, 6322 ql2322_fw.bin
24xx ql2400_fw.bin
Upon request, the driver caches the firmware image until the driver is unloaded.
Firmware images can be retrieved from:
ftp://ftp.qlogic.com/outgoing/linux/firmware/
-8<-------------------------------------------------------
The only thing that I did change was that I added "&& MODULES" to the depends line. However, this only causes the driver to be possible to build when you build a kernel with module support. Still tristate allows you to build it both as a module and as a driver built into the kernel. However, when built into the kernel the driver is unusable as it needs its firmware which it can't reach.
Is there any other way to specify that a functionality can only be built as a module, not built into the kernel?
In my firsta attempts to post about these tests my post ended up not on the mailing list but as a reply to Sam Ravnborg only, apologies for that...
Best regards Henrik
Re: tristate and bool not enogh for Kconfig anymore
Quoted 7 lines · On Sun, 21 Oct 2007 12:24:02 +0200 Henrik Carlqvist wrote:
Quoted 4 lines · On Sun, 21 Oct 2007 00:47:38 -0400 [email protected] wrote:
Quoted 3 lines · Sam Ravnborg
I assume
depends on MODULES
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
should do the trick.
Umm... I think that will work backwards, and give you
CONFIG_FOO=yif.f the kernel *supports* modules. What he needs is to be able to sayCONFIG_FOO=norCONFIG_FOO=m, but *ban*CONFIG_FOO=y.Yes, thats right, MODULES does not ban y as would be needed. As an example
Agreed.
Quoted 39 lines
I tried to do a quick test, I edited
drivers/scsi/qla2xxx/Kconfigto look like this:-8<------------------------------------------------------- config
SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support" depends on PCI && SCSI && MODULES
selectSCSI_FC_ATTRS
selectFW_LOADER
---help---
This qla2xxx driver supports all QLogic Fibre Channel PCI and PCIe host adapters.By default, firmware for the ISP parts will be loaded via the Firmware Loader interface.
ISP Firmware Filename
---------- -----------------
21xx ql2100_fw.bin
22xx ql2200_fw.bin
2300, 2312, 6312 ql2300_fw.bin
2322, 6322 ql2322_fw.bin
24xx ql2400_fw.binUpon request, the driver caches the firmware image until the driver is unloaded.
Firmware images can be retrieved from:
ftp://ftp.qlogic.com/outgoing/linux/firmware/
-8<-------------------------------------------------------The only thing that I did change was that I added "&& MODULES" to the depends line. However, this only causes the driver to be possible to build when you build a kernel with module support. Still tristate allows you to build it both as a module and as a driver built into the kernel. However, when built into the kernel the driver is unusable as it needs its firmware which it can't reach.
Quoted 2 lines
Is there any other way to specify that a functionality can only be built as a module, not built into the kernel?
config FOO
depends on BAR && m
restricts FOO to module-only.
Quoted 3 lines
In my firsta attempts to post about these tests my post ended up not on the mailing list but as a reply to Sam Ravnborg only, apologies for that...
---
~Randy
Re: tristate and bool not enogh for Kconfig anymore
Quoted 4 lines
config FOO
depends on BAR && mrestricts FOO to module-only.
Thanks alot! That really did the trick! With the following file:
-8<-------------------------------
config SCSI_QLA_FC
tristate "QLogic QLA2XXX Fibre Channel Support" depends on PCI && SCSI && m
select SCSI_FC_ATTRS
select FW_LOADER
---help---
This qla2xxx driver supports all QLogic Fibre Channel PCI and PCIe host adapters.
By default, firmware for the ISP parts will be loaded via the Firmware Loader interface.
ISP Firmware Filename
---------- -----------------
21xx ql2100_fw.bin
22xx ql2200_fw.bin
2300, 2312, 6312 ql2300_fw.bin
2322, 6322 ql2322_fw.bin
24xx ql2400_fw.bin
Upon request, the driver caches the firmware image until the driver is unloaded.
Firmware images can be retrieved from:
ftp://ftp.qlogic.com/outgoing/linux/firmware/
-8<-------------------------------
It is now only possible to compile the driver as a module.
Best regards Henrik
Signature · 3 lines
NOTE: Dear Outlook users: Please remove me from your address books.
Read this article and you know why:
http://newsforge.com/article.pl?sid=03/08/21/143258Re: tristate and bool not enogh for Kconfig anymore
In reply to Randy DunlapQuoted 11 lines · Randy Dunlap
Quoted 2 lines
Is there any other way to specify that a functionality can only be built as a module, not built into the kernel?
config FOO
depends on BAR && mrestricts FOO to module-only.
Quoted 3 lines
In my firsta attempts to post about these tests my post ended up not on the mailing list but as a reply to Sam Ravnborg only, apologies for that...
This is obviously the right solution.
Randy - we should document this somewhere together with more kconfig tips'n'tricks.
A new document or do we extend kconfig-language?
Sam
Re: tristate and bool not enogh for Kconfig anymore
Quoted 7 lines · On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote:
Quoted 6 lines · Randy Dunlap
Quoted 2 lines
Is there any other way to specify that a functionality can only be built as a module, not built into the kernel?
config FOO
depends on BAR && m
Quoted 8 lines
Quoted 5 lines
restricts FOO to module-only.
Quoted 3 lines
In my firsta attempts to post about these tests my post ended up not on the mailing list but as a reply to Sam Ravnborg only, apologies for that...
This is obviously the right solution.
Randy - we should document this somewhere together with more kconfig tips'n'tricks.
Agreed.
Quoted 1 line
A new document or do we extend kconfig-language?
I don't see a need for a separate document. I would just extend kconfig-language.
---
~Randy
Re: tristate and bool not enogh for Kconfig anymore
Quoted 11 lines · On Sun, 21 Oct 2007 17:47:48 -0700 Randy Dunlap wrote:
Quoted 9 lines · On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote:
Quoted 8 lines · Randy Dunlap
Quoted 2 lines
Is there any other way to specify that a functionality can only be built as a module, not built into the kernel?
config FOO
depends on BAR && mrestricts FOO to module-only.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
In my firsta attempts to post about these tests my post ended up not on the mailing list but as a reply to Sam Ravnborg only, apologies for that...
This is obviously the right solution.
Randy - we should document this somewhere together with more kconfig tips'n'tricks.Agreed.
So that's one tip or trick... or common idiom.
Quoted 4 lines
Quoted 1 line
A new document or do we extend kconfig-language?
I don't see a need for a separate document. I would just extend kconfig-language.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another common idiom that we see (and sometimes have problems with) is this:
When B (module or subsystem) uses interfaces from A (module or subsystem), A can be linked statically into the kernel image or
can be built as loadable module(s). This limits how B can be
built. If A is linked statically into the kernel image, B can be built statically or as loadable module(s). However, if A is built as loadable module(s), then B must be restricted to loadable module(s) also. This can be expressed in kconfig language as:
config B
depends on A = y || A = B
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's also a third issue: symbols that are specific to a particular $arch, but they are in Kconfig files that are common to all arches, so kconfig complains about symbol A refers to unknown symbol B. (and I'm just writing this from memory, not from testing it, so it could be off a bit.) One example of this was PS3_PS3AV, as copied from an lkml email of 2007-feb-14:
drivers/video/Kconfig:1604:warning: 'select' used by config symbol 'FB_PS3' refer to undefined symbol 'PS3_PS3AV'
Someone fixed this one by introducing an intermediate config symbol. I didn't follow the details of that fix, but we see this problem enough to warrant explaining how to handle it. E.g., recently (from 2007-oct-14) on lkml:
$ make oldconfig >/dev/null drivers/macintosh/Kconfig:121:warning: 'select' used by config symbol 'PMAC_APM_EMU' refers to undefined symbol 'APM_EMULATION'
Adrian, do you know of other items that should be listed here?
Thanks,
---
~Randy
Re: tristate and bool not enogh for Kconfig anymore
Quoted 61 lines · On Sun, 21 Oct 2007 20:14:16 -0700 Randy Dunlap wrote:
Quoted 11 lines · On Sun, 21 Oct 2007 17:47:48 -0700 Randy Dunlap wrote:
Quoted 9 lines · On Sun, 21 Oct 2007 23:03:13 +0200 Sam Ravnborg wrote:
Quoted 8 lines · Randy Dunlap
Quoted 2 lines
Is there any other way to specify that a functionality can only be built as a module, not built into the kernel?
config FOO
depends on BAR && mrestricts FOO to module-only.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
In my firsta attempts to post about these tests my post ended up not on the mailing list but as a reply to Sam Ravnborg only, apologies for that...
This is obviously the right solution.
Randy - we should document this somewhere together with more kconfig tips'n'tricks.Agreed.
So that's one tip or trick... or common idiom.
Quoted 4 lines
Quoted 1 line
A new document or do we extend kconfig-language?
I don't see a need for a separate document. I would just extend kconfig-language.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another common idiom that we see (and sometimes have problems with) is this:When B (module or subsystem) uses interfaces from A (module or subsystem), A can be linked statically into the kernel image or
can be built as loadable module(s). This limits how B can be
built. If A is linked statically into the kernel image, B can be built statically or as loadable module(s). However, if A is built as loadable module(s), then B must be restricted to loadable module(s) also. This can be expressed in kconfig language as:config B
depends on A = y || A = B~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's also a third issue: symbols that are specific to a particular $arch, but they are inKconfigfiles that are common to all arches, so kconfig complains about symbol A refers to unknown symbol B. (and I'm just writing this from memory, not from testing it, so it could be off a bit.) One example of this wasPS3_PS3AV, as copied from an lkml email of 2007-feb-14:drivers/video/Kconfig:1604:warning: 'select' used by config symbol '
FB_PS3' refer to undefined symbol 'PS3_PS3AV'Someone fixed this one by introducing an intermediate config symbol. I didn't follow the details of that fix, but we see this problem enough to warrant explaining how to handle it. E.g., recently (from 2007-oct-14) on lkml:
Quoted 7 lines
$ make oldconfig >/dev/null drivers/macintosh/Kconfig:121:warning: 'select' used by config symbol 'PMAC_APM_EMU' refers to undefined symbol 'APM_EMULATION'Adrian, do you know of other items that should be listed here?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Continuing with real-life kconfig fun, here's a fourth item that people need to be aware of.
The construct:
if ARCH_OMAP
source "drivers/video/omap/Kconfig"
endif
does not prevent kconfig from reading drivers/video/omap/Kconfig. Instead, it make all config symbols in that file be dependent upon the ARCH_OMAP symbol. Adding a config symbol dependency like this is a common problem that causes config menus not to be displayed as they should be (not indented or not subordinate as expected).
---
~Randy
Re: tristate and bool not enogh for Kconfig anymore
In reply to Randy DunlapHi,
Quoted 12 lines · Randy Dunlap
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another common idiom that we see (and sometimes have problems with) is this:When B (module or subsystem) uses interfaces from A (module or subsystem), A can be linked statically into the kernel image or
can be built as loadable module(s). This limits how B can be
built. If A is linked statically into the kernel image, B can be built statically or as loadable module(s). However, if A is built as loadable module(s), then B must be restricted to loadable module(s) also. This can be expressed in kconfig language as:
Quoted 2 lines
config B
depends on A = y || A = B
What you describe is a simple "depends on A" and your example won't work because it adds a recursive dependency.
bye, Roman
Re: tristate and bool not enogh for Kconfig anymore
In reply to Henrik CarlqvistQuoted 8 lines · Henrik Carlqvist
I think there is a need for
Kconfigto specify that a functionality could be built as a module or not built at all.Some drivers require that firmware is loaded when the driver is initialized. The kernel has functionalities for this by using a userspace program. However, this userspace program is only usable from modules and not during boot while any initrd or any other file system has not yet been mounted and yet less any processes started.
That's wrong. You can load firmware from the initramfs even if the
driver is built in. There is no valid reason why a driver shouldn't be allowed to be built in.
Re: tristate and bool not enogh for Kconfig anymore
Quoted 10 lines · Christoph Hellwig
Quoted 8 lines · Henrik Carlqvist
I think there is a need for
Kconfigto specify that a functionality could be built as a module or not built at all.Some drivers require that firmware is loaded when the driver is initialized. The kernel has functionalities for this by using a userspace program. However, this userspace program is only usable from modules and not during boot while any initrd or any other file system has not yet been mounted and yet less any processes started.
Quoted 3 lines
That's wrong. You can load firmware from the initramfs even if the
driver is built in. There is no valid reason why a driver shouldn't be allowed to be built in.
Could you please explain how this is supposed to work?
As far as I understand, the kernel initializes all built-in drivers, and only then starts /init in initramfs (which is then supposed to start udevd and load firmware) - but that's too late.
Signature · 1 line
Alexander E. Patrakov
Re: tristate and bool not enogh for Kconfig anymore
Quoted 9 lines · Alexander E. Patrakov
Quoted 3 lines
That's wrong. You can load firmware from the initramfs even if the
driver is built in. There is no valid reason why a driver shouldn't be allowed to be built in.Could you please explain how this is supposed to work?
As far as I understand, the kernel initializes all built-in drivers, and only then starts /init in initramfs (which is then supposed to start udevd and load firmware) - but that's too late.
populate_rootfs is a rootfs_initcall which happens before all the driver initcalls.
Re: tristate and bool not enogh for Kconfig anymore
Quoted 6 lines · Christoph Hellwig
Quoted 4 lines · Alexander E. Patrakov
Quoted 4 lines
That's wrong. You can load firmware from the initramfs even if the
driver is built in. There is no valid reason why a driver shouldn't be allowed to be built in.
Quoted 8 lines
Quoted 4 lines
Could you please explain how this is supposed to work?
As far as I understand, the kernel initializes all built-in drivers, and only then starts /init in initramfs (which is then supposed to start udevd and load firmware) - but that's too late.
populate_rootfsis arootfs_initcallwhich happens before all the driver initcalls.
Correct, but irrelevant. The firmware indeed gets unpacked to rootfs before all driver initcalls, but stays as a dead weight during them, because udev (started by /init, which happens in init_post() called by kernel_init() after all initcalls) is needed to load this firmware.
Yes, there is a call to usermodehelper_init() before the initcalls in do_basic_setup(), this does mean that firmware can be loaded by means of the old and obsolete /sbin/hotplug mechanism, but who has /sbin/hotplug now?
Signature · 1 line
Alexander E. Patrakov
Re: tristate and bool not enogh for Kconfig anymore
Quoted 3 lines · Alexander E. Patrakov
Yes, there is a call to
usermodehelper_init()before the initcalls indo_basic_setup(), this does mean that firmware can be loaded by means of the old and obsolete/sbin/hotplugmechanism, but who has/sbin/hotplugnow?
I do. We're not going to cripple the kernel just because you use fucked up userspace.
Re: tristate and bool not enogh for Kconfig anymore
Quoted 8 lines · Christoph Hellwig
Quoted 2 lines · Alexander E. Patrakov
Yes, there is a call to
usermodehelper_init()before the initcalls indo_basic_setup(), this does mean that firmware can be loaded by means of the old and obsolete/sbin/hotplugmechanism, but who has/sbin/hotplugnow?I do. We're not going to cripple the kernel just because you use <censored> userspace.
AFAIK, there were good reasons (effect similar to fork bomb on a system with large number of, e.g., SCSI disks - Greg KH obviously knows more details) to drop /sbin/hotplug from all distributions in favour of udev. Anyway, the "hotplug" package is no longer supported by its author. So there is no option to use a non-<censored> from your viewpoint but still supported-upstream userspace.
As already mentioned in a different subthread, the solution is to wait for the firmware in the background, so that the built-in case also starts working. Drivers that don't do this (e.g. qla2xxx) must be fixed, but for now, IMHO, it does make sense to mark them as non-working in the non-modular case.
Signature · 1 line
Alexander E. Patrakov
Re: tristate and bool not enogh for Kconfig anymore
In reply to Henrik CarlqvistQuoted 9 lines · Henrik Carlqvist
I think there is a need for
Kconfigto specify that a functionality could be built as a module or not built at all.Some drivers require that firmware is loaded when the driver is initialized. The kernel has functionalities for this by using a userspace program. However, this userspace program is only usable from modules and not during boot while any initrd or any other file system has not yet been mounted and yet less any processes started.
I cannot see a reason to outlaw built-in driver for this case. The device needing a firmware file is not an argument for making the driver modular only.
The idea for the fix is simple enough. Such a driver should not initialize just because the kernel itself boots up. It should wait until the firmware is provided. (which surely can be done from an initrd, so you can use that device as
the root fs if need be.)
Similar example: Drivers for all sorts of USB thingies can be built into the kernel. Still, these drivers don't initialize until hardware is plugged in. Which could happen weeks later. They just wait until a device is ready for use.
Surely other drivers can do the same - wait until the device is ready (firmware gets loaded) and start to use the device at that point.
Quoted 6 lines
For example, Slackware 12 has a huge kernel with a lot of drivers for different file systems and scsi cards built in. This kernel is supposed to be a non optimized kernel that works on almost any machine even without an initrd. In that kernel
CONFIG_SCSI_QLA_FCis set to y but still it is not possible to boot from any of those cards as the driver requires a firmware file.
Then an initrd-less boot is impossible for this device - even the modular approach needs
an initrd to load the module if you want that device as root fs.
Quoted 4 lines
Even together with an initrd image containing the firmware file it is still not possible to use the driver as the driver require the firmware file before any processes has been started from the initrd image.
So fix that! If the driver can wait for its firmware in the modular case, then it can wait for its firmware in the built-in case too. That capability may require some coding of course, but _depending_ on modularity is silly. There are enough people out there that simply don't want modules, and even leave out module support when compiling. There should be no need for modules when you compile the kernel specifically for
the machine.
Quoted 4 lines
For such drivers requiring firmware files, or if there is any other reason that the driver doesn't work when built into the kernel it would be useful with another choice than bool or tristate.
Better to just fix the driver - which can't be that hard for anyone capable of making the driver in the first place. Modularity and firmware loading are not connected. One is for kernel flexibility, the other is for making a particular device work.
Helge Hafting
Re: tristate and bool not enogh for Kconfig anymore
On Mon, 22 Oct 2007 13:46:43 +0200
Quoted 7 lines
Quoted 3 lines
In that kernel
CONFIG_SCSI_QLA_FCis set to y but still it is not possible to boot from any of those cards as the driver requires a firmware file.Then an initrd-less boot is impossible for this device - even the modular approach needs
an initrd to load the module if you want that device as root fs.
Today I was able to boot from an FC disk with a modified kernel 2.6.21 without any initrd. The modification was basically to replace the contents of drivers/scsi/qla2xxx with the code in qla2xxx-v8.02.02-dist.tgz from ftp://ftp.qlogic.com/outgoing/linux/beta/8.x/ as that driver has the firmware built in.
Quoted 5 lines
Better to just fix the driver - which can't be that hard for anyone capable of making the driver in the first place. Modularity and firmware loading are not connected. One is for kernel flexibility, the other is for making a particular device work.
In this case I finally did prefer a solution which didn't depend on any separate firmware file. Being able to boot straight to the FC drive without the need of initrd was really nice.
When I first asked my question I assumed that I would have to compile the driver as a module and use an initrd containing both the module and the firmware together with userspace mechanisms to load the firmware. This solution with a replaced qla2xxx driver was not the answer to my first question about bool and tristate, but that question also got answered in this thread.
Best regards Henrik
Am I the only one seeing this issue?
Quoted 7 lines · On Saturday 20 October 2007 12:57:55 Nick Warne wrote:
Hi all,
I noticed I had a module option being built that wasn't in menuconfig.
It is missing description. I also added a brief help message.
Signed off by: Nick Warne <[email protected]>
Not using this patch, using menuconfig the scsi_wait option doesn't appear anywhere for me to be able to it turn off - yet grep'ing .config will always show this option as being built as a module.
Nick
Signature · 1 line
Free Software Foundation Associate Member 5508
drivers/scsi/Kconfig renamed from drivers/scsi/Kconfig_old +8 -1
@@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "Wait for SCSI scan completion" default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu "SCSI Transports" depends on SCSI