1da177e4c3
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
148 lines
6.3 KiB
Text
148 lines
6.3 KiB
Text
LINUX HOTPLUGGING
|
|
|
|
In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
|
|
into the bus with power on. In most cases, users expect the devices to become
|
|
immediately usable. That means the system must do many things, including:
|
|
|
|
- Find a driver that can handle the device. That may involve
|
|
loading a kernel module; newer drivers can use module-init-tools
|
|
to publish their device (and class) support to user utilities.
|
|
|
|
- Bind a driver to that device. Bus frameworks do that using a
|
|
device driver's probe() routine.
|
|
|
|
- Tell other subsystems to configure the new device. Print
|
|
queues may need to be enabled, networks brought up, disk
|
|
partitions mounted, and so on. In some cases these will
|
|
be driver-specific actions.
|
|
|
|
This involves a mix of kernel mode and user mode actions. Making devices
|
|
be immediately usable means that any user mode actions can't wait for an
|
|
administrator to do them: the kernel must trigger them, either passively
|
|
(triggering some monitoring daemon to invoke a helper program) or
|
|
actively (calling such a user mode helper program directly).
|
|
|
|
Those triggered actions must support a system's administrative policies;
|
|
such programs are called "policy agents" here. Typically they involve
|
|
shell scripts that dispatch to more familiar administration tools.
|
|
|
|
Because some of those actions rely on information about drivers (metadata)
|
|
that is currently available only when the drivers are dynamically linked,
|
|
you get the best hotplugging when you configure a highly modular system.
|
|
|
|
|
|
KERNEL HOTPLUG HELPER (/sbin/hotplug)
|
|
|
|
When you compile with CONFIG_HOTPLUG, you get a new kernel parameter:
|
|
/proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug".
|
|
That parameter names a program which the kernel may invoke at various times.
|
|
|
|
The /sbin/hotplug program can be invoked by any subsystem as part of its
|
|
reaction to a configuration change, from a thread in that subsystem.
|
|
Only one parameter is required: the name of a subsystem being notified of
|
|
some kernel event. That name is used as the first key for further event
|
|
dispatch; any other argument and environment parameters are specified by
|
|
the subsystem making that invocation.
|
|
|
|
Hotplug software and other resources is available at:
|
|
|
|
http://linux-hotplug.sourceforge.net
|
|
|
|
Mailing list information is also available at that site.
|
|
|
|
|
|
--------------------------------------------------------------------------
|
|
|
|
|
|
USB POLICY AGENT
|
|
|
|
The USB subsystem currently invokes /sbin/hotplug when USB devices
|
|
are added or removed from system. The invocation is done by the kernel
|
|
hub daemon thread [khubd], or else as part of root hub initialization
|
|
(done by init, modprobe, kapmd, etc). Its single command line parameter
|
|
is the string "usb", and it passes these environment variables:
|
|
|
|
ACTION ... "add", "remove"
|
|
PRODUCT ... USB vendor, product, and version codes (hex)
|
|
TYPE ... device class codes (decimal)
|
|
INTERFACE ... interface 0 class codes (decimal)
|
|
|
|
If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is
|
|
the pathname of the device, and is useful for devices with multiple and/or
|
|
alternate interfaces that complicate driver selection. By design, USB
|
|
hotplugging is independent of "usbdevfs": you can do most essential parts
|
|
of USB device setup without using that filesystem, and without running a
|
|
user mode daemon to detect changes in system configuration.
|
|
|
|
Currently available policy agent implementations can load drivers for
|
|
modules, and can invoke driver-specific setup scripts. The newest ones
|
|
leverage USB module-init-tools support. Later agents might unload drivers.
|
|
|
|
|
|
USB MODUTILS SUPPORT
|
|
|
|
Current versions of module-init-tools will create a "modules.usbmap" file
|
|
which contains the entries from each driver's MODULE_DEVICE_TABLE. Such
|
|
files can be used by various user mode policy agents to make sure all the
|
|
right driver modules get loaded, either at boot time or later.
|
|
|
|
See <linux/usb.h> for full information about such table entries; or look
|
|
at existing drivers. Each table entry describes one or more criteria to
|
|
be used when matching a driver to a device or class of devices. The
|
|
specific criteria are identified by bits set in "match_flags", paired
|
|
with field values. You can construct the criteria directly, or with
|
|
macros such as these, and use driver_info to store more information.
|
|
|
|
USB_DEVICE (vendorId, productId)
|
|
... matching devices with specified vendor and product ids
|
|
USB_DEVICE_VER (vendorId, productId, lo, hi)
|
|
... like USB_DEVICE with lo <= productversion <= hi
|
|
USB_INTERFACE_INFO (class, subclass, protocol)
|
|
... matching specified interface class info
|
|
USB_DEVICE_INFO (class, subclass, protocol)
|
|
... matching specified device class info
|
|
|
|
A short example, for a driver that supports several specific USB devices
|
|
and their quirks, might have a MODULE_DEVICE_TABLE like this:
|
|
|
|
static const struct usb_device_id mydriver_id_table = {
|
|
{ USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X },
|
|
{ USB_DEVICE (0xbbbb, 0x8888), driver_info: QUIRK_Y|QUIRK_Z },
|
|
...
|
|
{ } /* end with an all-zeroes entry */
|
|
}
|
|
MODULE_DEVICE_TABLE (usb, mydriver_id_table);
|
|
|
|
Most USB device drivers should pass these tables to the USB subsystem as
|
|
well as to the module management subsystem. Not all, though: some driver
|
|
frameworks connect using interfaces layered over USB, and so they won't
|
|
need such a "struct usb_driver".
|
|
|
|
Drivers that connect directly to the USB subsystem should be declared
|
|
something like this:
|
|
|
|
static struct usb_driver mydriver = {
|
|
.name = "mydriver",
|
|
.id_table = mydriver_id_table,
|
|
.probe = my_probe,
|
|
.disconnect = my_disconnect,
|
|
|
|
/*
|
|
if using the usb chardev framework:
|
|
.minor = MY_USB_MINOR_START,
|
|
.fops = my_file_ops,
|
|
if exposing any operations through usbdevfs:
|
|
.ioctl = my_ioctl,
|
|
*/
|
|
}
|
|
|
|
When the USB subsystem knows about a driver's device ID table, it's used when
|
|
choosing drivers to probe(). The thread doing new device processing checks
|
|
drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and
|
|
device descriptors for the device. It will only call probe() if there is a
|
|
match, and the third argument to probe() will be the entry that matched.
|
|
|
|
If you don't provide an id_table for your driver, then your driver may get
|
|
probed for each new device; the third parameter to probe() will be null.
|
|
|
|
|