Hardware components that can be connected and disconnected from the system
while it is running are growing more common.
As well as USB, the most prominent example for this kind of
component, there are PCI, PCMCIA, Firewire, SCSI, and other interfaces.
Hotplug systems are responsible for recognizing newly-connected or
installed hardware and automatically making it available for
use. Components that will be removed again need,
furthermore, to be prepared for this event. If removed
without prior warning, resources must be freed again.
Little programs called daemons watch parts of a system for external events. The inetd daemon, for example, watches incoming network requests. The daemon for hotplugging is the kernel itself. The driver for an interface must be able to recognize new devices and report them to the system in a standardized way. USB, PCMCIA, Firewire, the network subsystem, and, to some extent, PCI are able to do this in the 2.4 kernel. This part of hotplugging is firmly built into the corresponding modules and cannot be influenced without changing the kernel.
Note
PCMCIA devices are only being handled by the hotplugging service if they are
CardBus cards and the PCMCIA system kernel was selected. They then
appear as PCI devices. More detailed information about this can be found
in the section on PCMCIA.
The second part of the hotplugging service initiates the necessary steps for the respective registration and release of devices and is a collection of scripts in the directory /etc/hotplug with the main script /sbin/hotplug. This script is the interface between the kernel and the collection of hotplugging scripts. These scripts are referred to as the ``hotplug system'' for the course of this chapter.
When a hot-pluggable device is connected or removed, the kernel calls the /sbin/hotplug/ script and passes additional information to the corresponding hardware component. This script directs the tasks -- depending on the type of hardware -- to additional scripts. These insert or remove the modules respectively and call other programs for the configuration of the components. These programs are located in /etc/hotplug and always end with .agent.
Although the kernel always passes hotplug events to /sbin/hotplug, the hotplug system needs to be started initially with the command rchotplug start. All hotplug events are discarded if hotplug has not been started.
Aside from this, there are components recognized by the kernel even before the file system can be accessed. These events are simply lost. This is why the scripts /etc/hotplug/*.rc attempt to create these events artificially for already existing hardware.
The term ``coldplugging'' is used in this respect. If the USB base modules have not been loaded until then, they are loaded and the USB device file system usbdefs is mounted.
After hotplug has been stopped by calling rchotplug stop, no more events can be evaluated. Hot-plugging can be completely deactivated if the hardware configuration is never changed during operation. This, however,requires other methods of installing USB or PCMCIA devices.
The path /etc/sysconfig/hotplug contains a few variables that control the behavior of hotplug. For instance, the variable <HOTPLUG_DEBUG> influences the verbosity of hotplug. The variables <HOTPLUG_START_USB>, <HOTPLUG_START_PCI>, and <HOTPLUG_START_NET> determine that only events of a certain type are evaluated. All the other variables are explained in detail in the corresponding subsections. All the hotplug messages are logged in the file /var/log/messages -- the system log.
When a new USB device is connected, the script /etc/hotplug/usb.agent determines an appropriate driver and ensures that it is loaded. This driver is not necessarily a kernel module. Many USB cameras, for instance, are directly accessed by applications.
The assignment of drivers to hardware is multistaged: First, the file /etc/hotplug/usb.usermap is checked for an entry that specifies whether this hardware should be handled by an application or by a dedicated initialization script. If neither is the case, an individual assignment to a kernel module is searched for in /etc/hotplug/usb.handmap. If nothing is found there (which is most often the case), the assignment table of the kernel, /lib/modules/<kernelversion>/modules.usbmap, is queried. An additional USB hardware scan is run at this point, which triggers further actions if KDE is used. An appropriate YaST configuration module is presented, for instance, for devices connected for the first time or applications are run for using the new device. This mechanism runs in parallel to the other actions triggered by /etc/hotplug/usb.agent.
USB devices are differently by the usb.agent, according to type:
There are some USB-specific variables in /etc/sysconfig/hotplug. <HOTPLUG_USB_HOSTCONTROLLER_LIST> contains the driver for the USB controller in the order in which loading is attempted. When a driver is loaded successfully, those modules that need to be unloaded on removal of the component are listed in <HOTPLUG_USB_MODULES_TO_UNLOAD>. All remaining USB modules are not unloaded, because it cannot be determined with certainty whether they are still required by a device. The variable <HOTPLUG_USB_NET_MODULES> contains the names of those modules that provide a network interface. A hardware descriptor for later reference on network events is stored when one of these modules is loaded. This process is logged in the system log.
PCMCIA cards require a careful scrutiny because hotplug only handles CardBus cards. This handling is furthermore only done if the PCMCIA system of the kernel is activated. This condition is explained in more detail in the software section of the PCMCIA chapter.
CardBus cards are, technically-speaking, almost PCI devices. This is why both are handled by the same hotplug script -- /etc/hotplug/pci.agent. It essentially determines a driver for the card and loads it. In addition to this, a record of where the new card has been connected (PCI bus or PCMCIA slots and the slot designator) is stored, so a later hotplug network event can read this information and select the correct configuration.
The determination of the drive is two-staged in this case: the file /etc/hotplug/pci.handmap is searched for individual settings and, if nothing was found, the PCI driver table of the kernel /lib/modules<kernelversion>/modules.pcimap is subsequently searched. To change the driver assignment, the file /etc/hotplug/pci.handmap should be altered, as the other list is overwritten on a kernel update.
Unlike with USB, no special actions are executed depending on the type of PCI or CardBus card. The kernel creates a hotplug network event for network cards, which induces the installation of the interface. Further action must ensue manually for all other cards. The hotplug system is, however, still being expanded in this respect.
As soon as the card is removed, the employed modules are unloaded again. Should this lead to problems with certain modules, this can be prevented by writing the names of those modules into <HOTPLUG_PCI_MODULES_NOT_TO_UNLOAD>.
When a new network interface is registered or unregistered in the kernel, the kernel creates a hotplug network event. This is evaluated by /etc/hotplug/net.agent. Only ethernet, token ring, and wireless LAN interfaces are currently taken into account. Other mechanisms exist for all other kinds of networks, like modems or ISDN. Network interfaces which are provided by PCMCIA cards and are handled by cardmanager instead of hotplug are likewise not handled here. A message then appears in the system log.
First, which hardware provides the interface is determined. Because the 2.4 kernel cannot provide such information, a record created following the USB or PCI event is used. Although this works well in most cases, it is regarded as a temporary quick fix only. For this reason, two network cards cannot be connected simultaneously. To use multiple hotplug-enabled network cards, connect them subsequently with the computer. A latency of a few seconds between connections is sufficient. This transmission of information is logged in /var/log/messages.
Insert additional individual actions to execute following the installation of a new network device in /sbin/ifup. Details about this can be found in ifup. It is also possible to apply different default routing depending on the connected hardware. Refer to route for details.
If the probing of the hardware behind the interface fails and only one hotplug network device is used, the description of the network hardware in /etc/sysconfig/hotplug can be written to the variable <HOTPLUG_NET_DEFAULT_HARDWARE>. This string must correspond to what should be used by /sbin/ifup for the allocation of the correct configuration. The variable <HOTPLUG_NET_TIMEOUT> determines for how long net.agent waits for a dynamically-created hardware desciption.
All the kinds of hotplugging-enabled devices not described above are currently not handled. Hotplugging, however, is undergoing massive development that depends heavily on the abilities of the kernel. It is expected that better possibilities will be offered with the kernel 2.6.