By default, usbd opens all setup endpoints found at #u/usb (which correspond to built-in hubs initialized by the kernel during boot). Paths to directories representing setup endpoints for hubs can be given as arguments to restrict usbd operation to such hubs.

When a device is attached, depending upon a configuration file compiled into usbd , the appropriate device driver may be started without user intervention. This mechanism can be used to statically link some USB device drivers into usbd itself. Initial configuration for setup endpoints is performed independently of this configuration.

Usbd provides a file interface used to change debugging flags, and also used by USB device drivers statically linked into usbd. By default, the file system is mounted (after) at /dev and a 9P connection is posted at /srv/usb.

Besides files provided by device drivers, the file usbdctl is always present in the file interface. It accepts these control requests:

debug n

Sets the debugging level to n.

fsdebug n

Sets the file system debugging level to n.

dump

Prints the list of devices and file systems known by usbd.

Usbd recognizes the following options:

-d

Print debugging diagnostics. Repeating the option increases verbosity.

-D

Print debugging diagnostics for the file system interface.

-m mnt

Mount the served file system at mnt.

-s srv

Post a 9P connection at #s/srv.

Configuration

Usbd can be configured to start drivers for devices matching one or more CSPs (hex representation of USB class, subclass and protocol), class, subclass, protocol, vendor id, or device id. When a new device is attached, usbd scans the configuration and, if an entry matches the device descriptor, starts the driver. If no driver is configured, the setup endpoint for the device is left configured to let the user start the driver by hand.

Configuration is via compilation because one of the options is to embed (link) the driver into the usbd binary. If the driver is embedded, usbd creates a process for it and calls its main entry point. Otherwise, usbd tries to locate the driver binary in /bin/usb and creates a process to execute it.

The configuration file, usbdb, has two sections: embed and auto. Each section includes lines to configure particular drivers. A driver may have more than one line if necessary. Each line includes the name of the driver (the base name of the binary) and one or more attributes of the form

name=value

The following attributes exist:

class

Value may be the name of the class or a number identifying the device class (using C syntax). The following class names are known: audio, comms, hid, printer, storage, hub, and data.

subclass

Value is the number of the device subclass.

proto

Value is the number of the device protocol.

csp

Value is the hexadecimal number describing the CSP for the device.

vid

Value is the vendor id.

did

Value is the device id.

args

This must be the last field. The value is the rest of the line, and is supplied as arguments to the driver process.

Several environment variables can be used to alter the behaviour of usbd, for example, for use in plan9.ini(8). usbdebug sets a debug level (zero for no diagnostics and positive values for increasing verbosity). kbargs overrides the keyboard arguments as specified by the configuration file. diskargs overrides the disk arguments in the same way.

embed kb csp=0x010103 csp=0x020103 args=-d auto disk class=storage args=

/srv/usb

9P connection to the driver file system.

/dev

mount point for the driver file system.

/sys/src/cmd/usb/usbd/usbdb

Configuration file deciding which devices are included into usbd and which ones are started automatically.

Not heavily exercised yet.