Henrik Carlqvist wrote:
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.
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.
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.
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.
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.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
