Behind the Scenes

Having spent the initial chapters of this book describing the architecture of Mac OS X, and in particular stating that a modern operating system only allows hardware to be directly accessed from the kernel, you are probably wondering how this is consistent with a chapter describing user-space drivers.

Internally, user-space drivers do indeed require a kernel driver, but this is provided by the same IOUSBDevice and IOUSBInterface objects that would be used to interact with the USB device had the developer chosen to write a kernel driver for the hardware. To make these objects available to user-space applications, the IOUSBFamily publishes a user client for each instance of IOUSBDevice and IOUSBInterface that is created in the kernel.

The user client that is created for these classes is extremely generic and exists solely to expose the methods of the IOUSBDevice and IOUSBInterface class to user space. For example, the user client for the IOUSBDevice class contains methods for getting and setting the active device configuration, performing a device request, and iterating the device's interfaces. The user client for the IOUSBInterface class contains methods for reading and writing data to a specified endpoint.

An application doesn't need to call the methods from the user client class directly; instead, the I/O Kit framework provides a high level API to control the hardware. This API is known as IOUSBLib. The layering involved in a user-space USB driver is shown in Figure 15-1. The custom code a developer needs to write exists only in the application layer; the layers below are common libraries provided by Apple as part of Mac OS X.

Although it isn't necessary to have an understanding of how the IOUSBLib is implemented, a little knowledge will help you understand each of the steps that an application performs to find and interact with a USB device from user space.

Figure 15-1. The layers through which a user-space driver accesses its USB hardware