USB HOTPLUGGINGIn hotpluggable busses like USB (and Cardbus PCI), end-users plug devicesinto the bus with power on.  In most cases, users expect the devices to becomeimmediately 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 modutils to      publish their device (and class) support to user utilities.    - Bind a driver to that device.  That's done using the USB      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 devicesbe immediately usable means that any user mode actions can't wait for anadministrator to do them:  the kernel must trigger them, either passively(triggering some monitoring daemon to invoke a helper program) oractively (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 involveshell scripts that dispatch to more familiar administration tools.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 itsreaction to a configuration change, from a thread in that subsystem.Only one parameter is required: the name of a subsystem being notified ofsome kernel event.  That name is used as the first key for further eventdispatch; any other argument and environment parameters are specified bythe subsystem making that invocation.A reference implementation of a /sbin/hotplug script is available at thehttp://www.linux-usb.org website, which works USB for but also knows how todelegate to any /etc/hotplug/$TYPE.agent policy agent present.USB POLICY AGENTThe USB subsystem currently invokes /sbin/hotplug when USB devicesare added or removed from system.  The invocation is done by the kernelhub daemon thread [khubd], or else as part of root hub initialization(done by init, modprobe, kapmd, etc).  Its single command line parameteris 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 isthe pathname of the device, and is useful for devices with multiple and/oralternate interfaces that complicate driver selection.Currently available policy agent implementations can load drivers formodules, and can invoke driver-specific setup scripts.  The newest onesleverage USB modutils support.  Later agents might unload drivers.USB MODUTILS SUPPORTCurrent versions of modutils will create a "modules.usbmap" file whichcontains the entries from each driver's MODULE_DEVICE_TABLE.  Such filescan be used by various user mode policy agents to make sure all the rightdriver modules get loaded, either at boot time or later. See <linux/usb.h> for full information about such table entries; or lookat existing drivers.  Each table entry describes one or more criteria tobe used when matching a driver to a device or class of devices.A short example, for a driver that supports several specific USB devicesand their quirks, might have a MODULE_DEVICE_TABLE like this:    static const struct usb_device_id mydriver_id_table = {	{ idVendor: 0x9999, idProduct 0xaaaa, driver_info: QUIRK_X },	{ idVendor: 0xbbbb, idProduct 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 aswell as to the module management subsystem.  Not all, though: some driverframeworks connect using interfaces layered over USB, and so they won'tneed such a "struct usb_driver".Drivers that connect directly to the USB subsystem should be declaredsomething 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 whenchoosing drivers to probe().  The thread doing new device processing checksdrivers' device ID entries from the MODULE_DEVICE_TABLE against interface anddevice descriptors for the device.  It will only call probe() if there is amatch, 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 getprobed for each new device; the third parameter to probe() will be null.