If a driver file in /lib/modules/<version>/<device-type>/*.o is either corrupted or removed, the system can find itself without critical resources. This can be fatal for critical processes and possibly result in a system crash. Recovery is not always obvious, but with a rescue disk the system can be rebooted and the state of /etc/modules and /lib/modules can be investigated. It is not always obvious that the problem is with the modules. But, having a printed listing of the files in /etc/modules (along with their file sizes) is a good tool to have in the recovery file folder when you start looking for solutions to problems.
Modules also provide a potential security risk. Using the ``exploit of the day'', a system cracker need only gain root access long enough to copy ``his'' version of the system PPP module to provide an ``undetectable'' TCP channel into the target machine with full root access. Any number of other drivers could be subverted in this fashion. This makes security even more important with a modular kernel at the heart of the system. Obviously the security hole is actually in the ``exploit of the day'' and not in the modules as delivered. Protecting the system from attacks of this nature is no more difficult than protecting from the ``exploit of the day''. Debian and Linux have a continued focus on security. Security breeches are announced in the appropriate news groups. Patches and their locations are announced as well.
Most important of the disadvantages of modular drivers and kerneld has to do with timing problems and unusual hardware configurations. With some devices, under certain load conditions, the time it takes kerneld to install and initialize the driver is long enough for the device to time out, resulting in a failed installation. So, if an FTP client calls for a network connection, and pppd isn't running, kerneld will kick off the appropriate processes and, depending on configuration, dial the number and establish the connection. In the mean time, however, the FTP client has timed out, waiting for the connection. The solution here is to try again with the FTP client. By this time the connection should be established and the connection will go through with no delay. This is not the best example, since the time delays are very large for a diald-type PPP connection even when everything is compiled into the kernel. If, however, this system did not time out the FTP connection without kerneld and modules, it would be likely to do so under some level of system load because of the additional time needed to load the modules from disk.
The other point has to do with special hardware configuration. If there is a modem that uses a nonstandard interrupt for the given slot location, the system will install the driver and configure it properly using setserial. However, if the driver isn't used for several minutes, it will be unloaded. When the driver is next needed, kerneld will load it, but knows nothing of the special configuration needs of the driver. This results in the driver trying to use the wrong interrupt for that device, and failing. The resulting symptom is that if the system establishes a PPP connection within the first several minutes of operation, the connection will be made in the standard fashion and work as expected. If, however, the system is allowed to sit quietly for several minutes after reboot, the PPP connection will never get established. The chat program (if that is how the connection is established) will time out waiting for the first response from the modem because it isn't servicing the proper interrupt. This can be fixed temporarily by issuing another call to setserial with the proper interrupt value for the card. The better fix is to explicitly name the device driver in /etc/modules. Adding serial to the list of modules in /etc/modules will cause the module to be loaded by init and, later in the boot process, configured with setserial. It will also have the beneficial side effect of causing kerneld to leave the module alone and never unload it. Thus, the configuration initially provided for this driver remains unaffected and the device continues to work properly.