USB Hotplugging

Linux hotplug 처리 흐름

USB와 CardBus PCI 같은 hotpluggable bus에서는 전원이 켜진 상태로 사용자가 device를 연결하며, 보통 즉시 사용할 수 있기를 기대합니다.

System은 device를 처리할 driver를 찾아야 합니다. 이 과정에서 kernel module을 load할 수 있고, 새 driver는 `module-init-tools`를 통해 지원 device와 class 정보를 user utility에 공개할 수 있습니다.

그다음 bus framework가 device driver의 `probe()` routine으로 driver를 device에 bind합니다. 이어 print queue 활성화, network 시작, disk partition mount 같은 작업을 다른 subsystem에 요청하며 일부는 driver-specific action일 수 있습니다.

이 흐름에는 kernel mode와 user mode 작업이 섞입니다. Device를 즉시 사용하려면 administrator의 수동 작업을 기다릴 수 없으므로 kernel은 monitoring daemon이 helper program을 실행하게 하는 passive 방식이나 user-mode helper를 직접 호출하는 active 방식으로 이를 trigger해야 합니다.

Trigger된 action은 system의 administrative policy를 따라야 하며, 여기서는 이를 수행하는 program을 `policy agent`라고 부릅니다. 보통 shell script가 익숙한 administration tool로 작업을 dispatch합니다.

일부 action은 driver가 dynamic link될 때만 현재 이용할 수 있는 metadata에 의존하므로 highly modular system으로 구성할 때 hotplugging이 가장 잘 동작합니다.

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

Kernel parameter `/proc/sys/kernel/hotplug`은 보통 `/sbin/hotplug` 경로를 담고 있으며, kernel이 여러 시점에 호출할 program을 지정합니다.

어떤 subsystem도 configuration change에 반응하는 자기 thread에서 `/sbin/hotplug`를 호출할 수 있습니다. 필수 parameter는 kernel event를 통지받는 subsystem 이름 하나이며, 이후 event dispatch의 첫 key로 사용됩니다.

나머지 argument와 environment parameter는 호출하는 subsystem이 정의합니다.

Hotplug software, resource와 mailing list 정보는 `http://linux-hotplug.sourceforge.net`에서 제공됩니다.

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와 환경 변수

USB subsystem은 USB device가 system에 추가되거나 제거될 때 `/sbin/hotplug`를 호출합니다. 호출은 kernel hub workqueue `hub_wq` 또는 init·modprobe·kapmd 등이 수행하는 root hub 초기화 과정에서 일어납니다.

Command-line parameter는 문자열 `usb` 하나이며 `ACTION`, `PRODUCT`, `TYPE`, `INTERFACE` environment variable을 전달합니다.

`usbdevfs`가 설정되어 있으면 `DEVICE`와 `DEVFS`도 전달됩니다. `DEVICE`는 device pathname이며 여러 interface 또는 alternate interface 때문에 driver 선택이 복잡한 device에 유용합니다.

USB hotplugging은 설계상 `usbdevfs`와 독립적입니다. 이 filesystem이나 system configuration 변경을 감지하는 user-mode daemon 없이도 USB device setup의 핵심 부분을 수행할 수 있습니다.

현재 policy agent 구현은 module driver를 load하고 driver-specific setup script를 호출할 수 있으며 최신 구현은 USB `module-init-tools` 지원을 활용합니다. 이후 agent는 driver unload도 수행할 수 있습니다.

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)
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와 device ID matching

현재 `module-init-tools`는 각 driver의 `MODULE_DEVICE_TABLE` entry를 모아 `modules.usbmap`을 만듭니다. User-mode policy agent는 이 file로 boot 시점이나 이후에 필요한 driver module이 모두 load되도록 할 수 있습니다.

Table entry의 전체 형식은 `linux/usb.h` 또는 기존 driver를 참고합니다. 각 entry는 driver를 특정 device 또는 device class와 match할 하나 이상의 기준을 설명합니다. `match_flags`에 설정된 bit가 어떤 field value를 비교할지 지정하고 `driver_info`에는 추가 정보를 저장할 수 있습니다.

`USB_DEVICE(vendorId, productId)`는 vendor·product ID가 같은 device를, `USB_DEVICE_VER(vendorId, productId, lo, hi)`는 product version이 `lo` 이상 `hi` 이하인 device를 match합니다. `USB_INTERFACE_INFO(class, subclass, protocol)`은 interface class 정보를, `USB_DEVICE_INFO(class, subclass, protocol)`은 device class 정보를 비교합니다.

여러 device와 quirk를 지원하는 table은 `static const struct usb_device_id` 배열에 `USB_DEVICE` entry와 `driver_info`를 두고 all-zero entry로 끝낸 뒤 `MODULE_DEVICE_TABLE(usb, mydriver_id_table)`로 공개합니다.

대부분 USB device driver는 이 table을 module management subsystem뿐 아니라 USB subsystem에도 전달해야 합니다. 다만 USB 위에 계층화된 interface로 연결되는 framework는 `struct usb_driver`가 필요하지 않을 수 있습니다.

USB subsystem에 직접 연결하는 driver는 `struct usb_driver`에 `.name`, `.id_table`, `.probe`, `.disconnect`를 지정합니다. USB chardev framework를 쓰면 `.minor`와 `.fops`, usbdevfs로 operation을 노출하면 `.ioctl`도 둘 수 있습니다.

USB subsystem이 ID table을 알고 있으면 새 device 처리 thread가 `MODULE_DEVICE_TABLE` entry를 interface·device descriptor와 비교합니다. Match가 있을 때만 `probe()`를 호출하며 세 번째 argument로 match된 entry를 넘깁니다. `id_table`이 없으면 모든 새 device에 대해 probe될 수 있고 세 번째 parameter는 `NULL`입니다.

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``.