C H A P T E R  5

Interacting with Drivers from Applications

In the previous chapter, we learnt about I/O Kit drivers, which live in the kernel. On the other hand, the applications that users interact with live in user space. So, if the user is going to use the services provided by your driver, the kernel/user space boundary needs to be crossed.

Mac OS X provides several different mechanisms through which a driver can provide its services to user space applications. The method that a developer chooses to allow a particular driver to provide its services to user space applications is dependent on the type of functionality that the driver implements. For example, all serial ports, audio drivers, and storage devices have their own interface that is defined by the I/O Kit. This interface allows a user space application to work with these devices. An application will work with devices provided by any hardware vendor, provided that the vendor's driver implements the standard I/O Kit interface for that device. From a driver developer's point of view, using the common interface provided by the I/O Kit is in their best interest because it ensures that the driver is accessible to a large number of user space applications without forcing developers to adopt a custom interface for the driver. It also requires less work on your part.

A good example of this is a serial port driver. A Mac OS X user space application accesses serial ports through a character device that is represented by a file in the /dev path of the file system. To communicate over a serial device, a user application calls the same functions as it would to open, read, or write to any other file on the file system; that is open(), read(), and write(). In the kernel, a driver that provides a serial port will create an instance of the standard I/O Kit class IOSerialStreamSync. The I/O Kit's serial family will create a device node in the /dev directory, publishing the path of the node in the I/O Registry so that applications can find it. It will also pass requests from user applications to method calls in the driver's implementation, which is a subclass of the standard IOSerialDriverSync class. There was no work required by the driver developer in publishing its services to user space. This is illustrated in Figure 5-1.

Figure 5-1. The classes involved in communicating with a serial port from a user space application. With the exception of MySerialDriver, all of the objects and their connections are created by the I/O Kit.

Not all driver developers are as fortunate as the developers of a serial port driver in having the I/O Kit take care of crossing the user space/kernel boundary. For a hardware device that provides custom functionality, the I/O Kit may not provide an appropriate client interface that your driver is able to use. In this case, your driver will need to implement a custom interface for user space applications to use when interacting with it. As we saw in Chapter 1, Mac OS X has a strict barrier between user space and the kernel. This places restrictions on the nature of how this interaction takes place. This chapter describes the methods provided by the I/O Kit to cross the user/kernel boundary and allow communication between user applications and a kernel driver.