login
Search
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 <nick@ukfsn.org> Nick -- Free Software Foundation Associate Member 5508
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
--
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/143258
-
I assume depends on MODULES should do the trick. Sam -
Some modules use (e.g.) depends on PCMCIA and m but using MODULES does make more sense to me. --- ~Randy -
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.gz CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_MODULE_VERIFY_ELF=y
On Sun, 21 Oct 2007 00:47:38 -0400
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
-
config FOO depends on BAR && m --- ~Randy -
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
--
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/143258
-
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 -
I don't see a need for a separate document. I would just extend kconfig-language. --- ~Randy -
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 -
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 -
Hi, What you describe is a simple "depends on A" and your example won't work because it adds a recursive dependency. bye, Roman -
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. -- Alexander E. Patrakov -
populate_rootfs is a rootfs_initcall which 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? -- Alexander E. Patrakov -
I do. We're not going to cripple the kernel just because you use fucked up 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. -- Alexander E. Patrakov -
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 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 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 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 -
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 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? 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 -- Free Software Foundation Associate Member 5508
