Documentation/driver-api/usb/hotplug.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/usb/hotplug.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/usb/hotplug.rst
Extension
.rst
Size
6572 bytes
Lines
155
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

USB hotplugging
~~~~~~~~~~~~~~~

Linux Hotplugging
=================


In hotpluggable buses 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``)
=========================================

There is a 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 workqueue [hub_wq], 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)

Annotation

Implementation Notes