This section gives specific details regarding the support for loadable kernel modules and how it relates to SCSI.
Loadable modules are a means by which the user or system administrator can load files into the kernel's memory in such a way that the kernel's capabilities are expanded. The most common usages of modules are for drivers to support hardware, or to load filesytems.
There are several advantages of modules for SCSI. One is that a system administrator trying to maintain a large number of machines can use a single kernel image for all of the machines, and then load kernel modules to support hardware that is only present on some machines.
It is also possible for someone trying to create a distribution to use a script on the bootable floppy to query for which modules to be loaded. This saves memory that would otherwise be wasted on unused drivers, and it would also reduce the possibility that a probe for a non-existent card would screw up some other card on the system.
Modules also work out nicely on laptops, which tend to have less memory than desktop machines, and people tend to want to keep the kernel image as small as possible and load modules as required. Also, modules makes supporting PCMCIA SCSI cards on laptops somewhat easier, since you can load and unload the driver as the card is inserted/removed. [Note: currently the qlogic and 152x drivers support PCMCIA].
Finally, there is the advantage that kernel developers can more easily debug and test their drivers, since testing a new driver does not require rebooting the machine (provided of course that the machine has not completely crashed as a result of some bug in the driver).
Although modules are very nice, there is one limitation. If your root disk partition is on a scsi device, you will not be able to use modularized versions of scsi code required to access the disk. This is because the system must be able to mount the root partition before it can load any modules from disk. There are people thinking about ways of fixing the loader and the kernel so that the kernel can self-load modules prior to attempting to mount the root filesystem, so at some point in the future this limitation may be lifted.
In the 1.2.N series of kernels, there is partial support for SCSI kernel modules. While none of the high level drivers (such as disk, tape, etc) can be used as modules, most of the low level drivers (i.e. 1542, 1522) can be loaded and unloaded as required. Each time you load a low-level driver, the driver first searches for cards that can be driven. Next, the bus is scanned for each card that is found, and then the internal data structures are set up so as to make it possible to actually use the devices attached to the cards that the driver is managing.
When you are through with a low-level driver, you can unload it. You should keep in mind that usage counts are maintained based upon mounted filesystems, open files, etc, so that if you are still using a device that the driver is managing, the rmmod utility will tell you that the device is still busy and refuse to unload the driver. When the driver is unloaded, all of the associated data structures are also freed so that the system state should be back to where it was before the module was loaded. This means that the driver could be reloaded at a later time if required.
In the 1.3 series of kernels, the scsi code is completely modularized. This means that you can start with a kernel that has no scsi support whatsoever, and start loading modules and you will eventually end up with complete support.
If you wish, you can compile some parts of the SCSI code into the kernel and then load other parts later - it is all up to you how much gets loaded at runtime and how much is linked directly into the kernel.
If you are starting with a kernel that has no support whatsoever for SCSI, then the first thing you will need to do is to load the scsi core into the kernel - this is in a module called "scsi_mod". You will not be able to load any other scsi modules until you have this loaded into kernel memory. Since this does not contain any low-level drivers, the act of loading this module will not scan any busses, nor will it activate any drivers for scsi disks, tapes, etc. If you answered 'Y' to the CONFIG_SCSI question when you built your kernel, you will not need to load this module.
At this point you can add modules in more or less any order to achieve the desired functionality. Usage counts are interlocks are used to prevent unloading of any component which might still be in use, and you will get a message from rmmod if a module is still busy.
The high level drivers are in modules named "sd_mod", "sr_mod", "st", and "sg", for disk, cdrom, tape, and scsi generics support respectively. When you load a high level driver, the device list for all attached hosts is examined for devices which the high level driver can drive, and these are automatically activated.
The use of modules with low level drivers were described in the section of the modules under 1.2 kernels. When a low-level driver is loaded, the bus is scanned, and each device is examined by each of the high level drivers to see if they recognize it as something that they can drive - anything recognized is automatically attached and activated.