Hot Plug

Examples

The /sbin/hotplug script can be a very simple script if you only want it to control a small number of devices. For example, if you have a USB mouse and wish to load and unload the kernel driver whenever the mouse is inserted or removed, the following script, located at /sbin/hotplug, would be sufficient:

#!/bin/sh
if [ "$1" = "usb" ]; then
    if [ "$INTERFACE" = "3/1/2" ]; then
        if [ "$ACTION" = "add" ]; then
            modprobe usbmouse
        else
            rmmod usbmouse
        fi
    fi
fi

Or if you want to run ColdSync (www.ooblick.com/software/coldsync) automatically when you connect your USB HandSpring Visor to the computer, the following script located at /sbin/hotplug would work well:

#!/bin/sh
USER=gregkh
if [ "$1" = "usb" ]; then
    if [ "$PRODUCT" = "82d/100/0" ]; then
        if [ "$ACTION" = "add" ]; then
            modprobe visor
            su $USER - -c "/usr/bin/coldsync"
        else
            rmmod visor
        fi
    fi
fi
If you want to make sure that your network devices always come up connected to the proper Ethernet card, the following /sbin/hotplug script, contributed by Sukadev Bhattiprolu, can do this:
#!/bin/sh
if [ "$1" = "network" ]; then
    if [ "$ACTION" = "register" ]; then
        nameif -r $INTERFACE -c /etc/mactab
    fi
fi
Listing 1 shows a more complex example that can handle automatically loading and unloading modules for three different USB devices.

Listing 1. Script to Load and Unload Modules Automatically for Three Different USB Devices

Need for Automation

The previous small example shows the limitations of being forced to enter in all of the different device IDs manually, product IDs and such in order to keep a /sbin/hotplug script up to date with all of the different devices that the kernel knows about. Instead, it would be better for the kernel itself to specify the different types of devices that it supports in such a way that any user-space tools could read them. Thus was born a macro called MODULE_DEVICE_TABLE() that is used by all USB and PCI drivers. This macro describes which devices each specific driver can support. At compilation time, the build process extracts this information out of the driver and builds a table. The table is called modules.pcimap and modules.usbmap for all PCI and USB devices, respectively, and exists in the directory /lib/modules/kernel_version/.

For example, the following code snippet from drivers/net/eepro100.c:

static struct pci_device_id eepro100_pci_tbl[]
__devinitdata = {
    { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82557,
      PCI_ANY_ID, PCI_ANY_ID, },
    { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82562ET,
      PCI_ANY_ID, PCI_ANY_ID, },
        { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL
          _82559ER, PCI_ANY_ID, PCI_ANY_ID,
},
        { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL
          _ID1029, PCI_ANY_ID, PCI_ANY_ID,
},
        { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL
          _ID1030, PCI_ANY_ID, PCI_ANY_ID,
},
        { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL
          _82801BA_7, PCI_ANY_ID, PCI_ANY_ID,
},
        { 0,}
    };
    MODULE_DEVICE_TABLE(pci, eepro100_pci_tbl);

causes these lines to be added to the modules.pcimap file:

eepro100 0x00008086 0x00001229 0xffffffff 0xffffffff
0x00000000 0x00000000 0x00000000
eepro100 0x00008086 0x00001031 0xffffffff 0xffffffff
0x00000000 0x00000000 0x00000000
eepro100 0x00008086 0x00001209 0xffffffff 0xffffffff
0x00000000 0x00000000 0x00000000
eepro100 0x00008086 0x00001029 0xffffffff 0xffffffff
0x00000000 0x00000000 0x00000000
eepro100 0x00008086 0x00001030 0xffffffff 0xffffffff
0x00000000 0x00000000 0x00000000
eepro100 0x00008086 0x00002449 0xffffffff 0xffffffff
0x00000000 0x00000000 0x00000000
As the example shows, a PCI device can be specified by any of the same parameters that are passed to the /sbin/hotplug program.

A USB device can specify that it can accept only specific devices such as this example from drivers/usb/mdc800.c:

static struct usb_device_id
  mdc800_table [] = {
   { USB_DEVICE(MDC800_VENDOR_ID, MDC800_PRODUCT_ID) },
   { } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, mdc800_table);

which causes the following line to be added to the modules.usbmap file:

mdc800 0x0003 0x055f 0xa800 0x0000 0x0000 0x00 0x00
0x00 0x00 0x00 0x00 0x00000000
Or it can specify that it accepts any device that matches a specific USB class code, as in this example from drivers/usb/printer.c:
static struct usb_device_id usblp_ids [] = {
  { USB_INTERFACE_INFO(USB_CLASS_PRINTER, 1, 1) },
  { USB_INTERFACE_INFO(USB_CLASS_PRINTER, 1, 2) },
  { USB_INTERFACE_INFO(USB_CLASS_PRINTER, 1, 3) },
  { }    /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usblp_ids);
which causes the following lines to be added to the modules.usbmap file:
printer 0x0380 0x0000 0x0000 0x0000 0x0000 0x00 0x00
0x00 0x07 0x01 0x01 0x00000000
printer 0x0380 0x0000 0x0000 0x0000 0x0000 0x00 0x00
0x00 0x07 0x01 0x02 0x00000000
printer 0x0380 0x0000 0x0000 0x0000 0x0000 0x00 0x00
0x00 0x07 0x01 0x03 0x00000000
Again these USB examples show that the information in the modules.usbmap file matches the information provided to /sbin/hotplug by the kernel, enabling /sbin/hotplug to determine which driver to load without relying on a hand-generated table, as PCMCIA does.

______________________

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Webcast
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot