==================================
ϡ
linux-2.6.13-rc3/Documentation/usb/hotplug.txt 
Ǥ
Ρ JF ץ < http://www.linux.or.jp/JF/ >
  2005/8/2
  Hiroshi.Suzuki < setter at reset dot jp >
  Chie Nakatani  <jeanne at mbox dot kyoto-inet dot or dot jp>
==================================
LINUX HOTPLUGGING

LINUX ۥåȥץ饰

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:

USB(ӡɥХ PCI) Τ褦ʡۥåȥץ饰ǽʥХǤϡɥ桼
Ÿä֤ǥǥХХ³ޤۤȤɤξ硢桼Ϥ˥ǥХ
Ȥ褦ˤʤäߤȻפäƤޤϡƥब˼Ȥޤơ
¿λ򤷤ʤФʤʤȤ̣ޤ:

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

    - ǥХ򰷤ɥ饤Фõͥ⥸塼ɤ뤫⤷ޤ;
      꿷ɥ饤Фϡ桼桼ƥƥ˥ǥХ(ӡ饹)ݡ
      뤿ˡmodule-init-tools Ȥޤ

    - Bind a driver to that device.  Bus frameworks do that using a
      device driver's probe() routine.

    - ǥХ˥ɥ饤ФХɤ롣Хե졼ǥХɥ饤Ф 
      probe() 롼ȤäƹԤޤ

    - 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)

ͥۥåȥץ饰إѡ (/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.

CONFIG_HOTPLUG Ȥ߹ȡͥѥ᡼Ȥޤ
/proc/sys/kernel/hotplug  (Ƥ̾ѥ̾ "/sbin/hotplug" ˤʤޤ)
Υѥ᡼ˤϡͥ뤬ˤ˵ưץꤷޤ

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.

/sbin/hotplug ץѹ뤿ᡢΥ֥ƥˤ륹
åɤ顢ȿΰʬΤ褦ʤɤʥ֥ƥˤäƤⵯư
ޤѥ᡼ϤҤȤĤɬפǤ:
륫ͥ륤٥ȤˤĤΤƤ륵֥ƥ̾ˤʤޤ
̾ϡʤ륤٥ȥǥѥåǡǽΥȤƻѤޤ;
¾ΰӡĶѿϡ֥ƥ൯ưꤵޤ

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 ݥꥷ

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:

ߡUSB ֥ƥϡUSB ǥХդ줿Ȥˡ/sbin/hotplug ưޤ
ưϡͥϥ֥ǡ󥹥å [khubd] 䡢롼ȥϥֽΰ
(init, modprobe, kapmd, ʤ) ˤ¹ԤޤΰĤΥޥɥ饤ѥ᡼ϡ
ʸ "usb" ǡ˼褦ʴĶѿϤޤ:

    ACTION ... "add", "remove"
    PRODUCT ... USB vendor, product, and version codes (hex)
    TYPE ... device class codes (decimal)
    INTERFACE ... interface 0 class codes (decimal)

    ACTION ... "add", "remove"
    PRODUCT ... USB ٥, ץ, С󥳡(16ʿ)
    TYPE ... ǥХ饹 (10ʿ)
    INTERFACE ... 󥿥ե 0 饹 (10ʿ)

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.

"usbdevfs" Ȥ߹ޤƤ硢 DEVICE  DEVFS Ϥޤ
DEVICE ϡǥХΥѥ̾ǡɥ饤ˤ롢ʣ /ޤ 
󥿥եĥǥХͭǤͤǡUSB ۥåȥץ饰 ϡ
"usbdevfs" Ȥϡ̵طǤ: USB ǥХΤۤȤɤδŪϡ
Υե륷ƥȤɬפޤ󡣤ˡƥѹ򸡽Ф
桼⡼ɥǡ¹ԤɬפϤޤ

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 module-init-tools ΥݡȤƳƤޤȤǡȤϥ⥸塼
ɤǤޤ

USB MODUTILS SUPPORT

USB MODUTILS ݡ

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. 

ԥС module-init-tools ϡ줾Υɥ饤ФΡMODULE_DEVICE_TABLE 
Υȥޤࡢ"modules.usbmap" եޤ
Τ褦ʥեϡ֡Ȼ䡢ʸˡɥ饤Х⥸塼뤬ɤ줿Τ
ǧ뤿ˡǤդΥ桼⡼ɥݥꥷȤǻȤޤ

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.

Τ褦ʥơ֥륨ȥˤĤƤϡ<linux/usb.h> 򸫤Ƥ;
ޤϡ¸ߤɥ饤Ф򸫤Ƥ줾Υơ֥륨ȥϡ
ɥ饤ФǥХ뤤ϥǥХΥ饹˹äƤʤȤϤΡ
ҤȤĤ뤤Ϥʾδ򵭽ҤƤޤ
δϡ"match_flags" ΥӥåȥåȤȡեͤФǡ
̤ޤľܡޤϡΤ褦ʥޥǺ뤳ȤǤޤޤ
ܺپ¸뤿ˡdriver_info ȤäƤ

    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

    USB_DEVICE (vendorId, productId)
	... ꤷ٥ȥץIDǡǥХȾȹ礹
    USB_DEVICE_VER (vendorId, productId, lo, hi)
	... USB_DEVICE Ʊͤǡ lo <= productversion <= hi Ȥʤ
    USB_INTERFACE_INFO (class, subclass, protocol)
	... ꤷ󥿥ե饹Ǿȹ礹
    USB_DEVICE_INFO (class, subclass, protocol)
	... ꤷǥХ饹Ǿȹ礹롣

A short example, for a driver that supports several specific USB devices
and their quirks, might have a MODULE_DEVICE_TABLE like this:

ħŪ USB ǥХ򥵥ݡȤɥ饤ФȡäȤΤ
ǥХ򥵥ݡȤɥ饤Фˤϡ˼褦 MODULE_DEVICE_TABLE 
뤫⤷ޤ:

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

ۤȤɤ USB ǥХɥ饤Фϡơ֥⥸塼֥ƥࡢ
ӡ USB ֥ƥϤʤФʤޤ󡣤٤ƤȤϸ¤ޤ󤬡ĤΥɥ饤
ե졼ˤ USB ˽Ťͤ줿󥿥եѤ³Τ⤢ꡢ
ϤΤ褦ʡ"struct usb_driver" פȤޤ

Drivers that connect directly to the USB subsystem should be declared
something like this:

USB ֥ƥľ³ɥ饤ФϡΤ褦ʤФʤޤ:

    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,
	*/

	/*
	usb chardev ե졼Ĥʤ:
	    .minor		= MY_USB_MINOR_START,
	    .fops		= my_file_ops,
	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.

USB ֥ƥबɥ饤ФΥǥХ ID ơ֥򤹤ȡϡprobe() Ϥɥ饤Ф
򤹤Τ˻ȤޤǥХԤåɤϡǥХΤΥ󥿥եȡ
ǥХǥץФơMODULE_DEVICE_TABLE Υɥ饤ФΥǥХ ID ȥ
ȹ礷ޤפ硢ϡprobe() ƤӽФǤޤprobe() Ϥ3ܤΰϡ
פȥˤʤޤ

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.

ɥ饤ФΤ id_table ʤʤ顢ɥ饤ФϤ줾οǥХΤĴ줿ʪޤ;
probe() Ϥ3ܤΥѥ᡼̵ˤʤޤ
