The Design and Implementation of the Anykernel and Rump Kernels

149
3.10 Hardware Device Drivers: A Case of USB
Hardware device drivers require access to their counterpart to function. This counterpart
can either be hardware itself or software which emulates the hardware.
Throughout this section our default assumption is that the virtualized driver is controlling
real hardware. Hardware access means that the hardware must be present
on the system where the driver is run and that the driver has to have the appropriate
privileges to access hardware. Access is typically available only when the CPU is
operating in privileged (kernel) mode.
The kernel USB driver stack exports USB device access to userspace via the USB
generic driver, or ugen. After ugen attaches to a USB bus node, it provides access
to the attached hardware (i.e. not the entire USB bus) from userspace via the
/dev/ugen device nodes. While hardware must still be present, providing access
via a device node means that any entity on the host with the appropriate privileges
to access the device node may communicate with the hardware. A key point is that
the USB protocol offered by ugen is essentially unchanged from the USB hardware
protocol. This protocol compatibility allows preexisting kernel drivers to use ugen
without protocol translation.
Our main goal with USB support was to show it is possible to do kernel hardware
device driver development in userspace. The two subproblems we had to solve were
being able to attach drivers to the ugen device nodes and to integrate with the
device autoconfiguration subsystem [108].
3.10.1 Structure of USB
At the root of the USB bus topology is a USB host controller. It controls all traffic
on the USB bus. All device access on the bus is done through the host controller