Before You Begin

You might have developed device drivers for other platforms—Mac OS 9, perhaps, or BSD or another flavor of UNIX. One thing you’ll discover reading this document is how different the approach is with the I/O Kit. Although writing drivers for OS X requires new ways of thinking and different ways of programming, you are amply rewarded for shifting to this new approach. The I/O Kit simplifies driver development and supports many categories of devices. Once you get the basics of the I/O Kit down, you’ll find it a relatively easy and efficient matter to create device drivers.

Before you attempt driver development with the I/O Kit, Apple highly recommends certain prerequisites. Because the framework uses an object-oriented programming model, which is implemented in a restricted subset of C++, it helps to know C++ or object-oriented concepts in general. Also, device drivers are not the same thing as applications because, being kernel-resident, they must abide by more restrictive rules. Knowledge of kernel programming is therefore very useful.

Indeed, programming in the kernel is discouraged except when it is absolutely necessary. Many alternatives for communicating with hardware and networks exist at higher levels of the system, including the “device interface” feature of the I/O Kit described in Controlling Devices From Outside the Kernel See Should You Program in the Kernel? for more on alternatives to kernel programming.

I/O Kit Features

From its inception, the fundamental goal for the I/O Kit has been to accommodate and augment native features and capabilities of OS X, particularly those of the kernel environment. As the driver model for OS X, the I/O Kit supports the following features:

• Dynamic and automatic device configuration (plug-and-play)

• Many new types of devices, including graphics acceleration and multimedia devices

• Power management (for example, “sleep” mode)

• The kernel’s enforcement of protected memory—separate address spaces for kernel and user programs

• Preemptive multitasking

• Symmetric multiprocessing

• Common abstractions shared between types of devices

• Enhanced development experience—new drivers should be easy to write

The I/O Kit supports these kernel features with its new model for device drivers and adds some additional features:

• An object-oriented framework implementing common behavior shared among all drivers and types (families) of drivers

• Many families for developers to build upon

• Threading, communication, and data-management primitives for dealing with issues related to multiprocessing, task control, and I/O-transfers

• A robust, efficient match-and-load mechanism that scales well to all bus types

• The I/O Registry, a database that tracks instantiated objects (such as driver instances) and provides information about them

• The I/O Catalog, a database of all I/O Kit classes available on a system

• A set of device interfaces—plug-in mechanisms that allows applications and other software in “user space” to communicate with drivers

• Excellent overall performance

• Support for arbitrarily complex layering of client and provider objects

The I/O Kit’s object-oriented programming model is implemented in a restricted subset of C++. Object-orientation just in itself is an advantage in driver development because of the code reusability it fosters. Once you are familiar with the I/O Kit, you can write device drivers much more quickly and efficiently than you can using a procedural model. In addition, code reusability decreases the memory footprint of drivers; drivers ported from Mac OS 9, for example, have been up to 75% smaller in OS X.

Design Principles of the I/O Kit

OS X is largely the product of two strains of operating-system technology: Mac OS 9 (and its predecessors) and BSD. Given this pedigree, one might have expected Apple to adopt the device-driver model of Mac OS 9 or FreeBSD. Instead, Apple chose to redesign the model. Several reasons motivated this decision.

First, neither the Mac OS 9 driver model nor the FreeBSD driver model offers a set of features rich enough to meet the needs of OS X. The OS X kernel is significantly more advanced than its Mac OS precursors; it handles memory protection, preemptive multitasking, multiprocessing, and other features not present in previous versions of Mac OS. Although FreeBSD is capable of handling these features, the BSD model does not offer other features expected in a modern operating system, including automatic configuration, driver stacking, power management, and dynamic loading of devices.

Thus the primary motivation behind the I/O Kit was the inadequacy of the currently available driver models. The redesign of the I/O architecture had to take advantage of and support the operating-system features of OS X. Toward this end, the I/O Kit’s designers settled on an object-oriented programming model that abstracted the kernel capabilities and hardware of an OS X system and provided a view of this abstraction to the upper layers of the operating system. The compelling part of this abstraction is the implementation of behavior common to all device drivers (or types of device drivers) in the classes of the I/O Kit.

As an example, consider virtual memory. In Mac OS 9, virtual memory is not a fundamental part of the operating system; it is an option. Because of this, a developer must always take virtual memory into account when creating a driver, and this raises certain complications. In contrast, virtual memory is an inherent capability of OS X and cannot be turned off. Because virtual memory is a fundamental and assumed capability, knowledge of it is incorporated into system software and driver writers do not have to take it into account.

The I/O Kit functions as a kind of foundation and coordinator for device drivers. This is a departure from previous driver models. In Mac OS 9, all software development kits (SDKs) are independent of each other and duplicate common functionality. OS X delivers the I/O Kit as part of a single kernel development kit (KDK); all portions of the KDK rest on common underpinnings. OS X helps developers take advantage of hardware complexity without requiring them to encode software complexity into each new device driver. In most cases, they need only add the specific code that makes their drivers different.

Another part of the design philosophy of the I/O Kit is to make the design completely open. Rather than hiding APIs in an attempt to protect developers from themselves, all I/O Kit source code is available as part of Darwin. Developers can use the source code as an aid to designing (and debugging) new drivers.

Limitations of the I/O Kit

Although the I/O Kit supports most types of hardware on an OS X system, it does not fully support all hardware. One category of such devices are those used for imaging, among them printers, scanners, and digital cameras. The I/O Kit provides only limited support for these devices, handling communication with these devices through the FireWire and USB families. Applications or other programs in user space are responsible for controlling the particular characteristics of these devices (see Controlling Devices From Outside the Kernel for details). If your application needs to drive an imaging device, you should use the appropriate imaging software development kit (SDK).

Although the I/O Kit attempts to represent the hierarchy and dynamic relationships among hardware devices and services in an OS X system, some things are difficult to abstract. It is in these gray areas of abstraction, such as when layering violations occur, that driver writers are more on their own. Even when the I/O Kit representation is clean and accurate, the reusability of I/O Kit family code can be limited. All hardware can have its own quirks and a driver’s code must take these quirks into account.

Language Choice

Apple considered several programming languages for the I/O Kit and chose a restricted subset of C++.

C++ was chosen for several reasons. The C++ compiler is mature and the language provides support for system programming. In addition, there is already a large community of Macintosh (and BSD) developers with C++ experience.

The restricted subset disallows certain features of C++, including

• Exceptions

• Multiple inheritance

• Templates

• Runtime type information (RTTI)—the I/O Kit uses its own implementation of a runtime typing system

These features were dropped because they were deemed unsuitable for use within a multithreaded kernel. If you feel you need these features, you should reconsider your design. You should be able to write any driver you require using I/O Kit with these restrictions in place.

namespace com.mycompany {

    class com.mycompany.driver.myClass : public IOService { // This is not allowed.

        OSDeclareDefaultStructors (com.mycompany.driver.myClass);

    };

};

kld():Undefined symbols:

__cxa_guard_acquire

__cxa_guard_release

class com_mycompany_driver_mystaticclass;

void com_mycompany_driver_myclass::myfunction(void)

{

    static com_mycompany_driver_mystaticclass staticclass;

    staticclass.anotherfunction();

}

class com_mycompany_driver_mystaticclass;

static com_mycompany_driver_mystaticclasss staticclass;

void com_mycompany_driver_myclass::myfunction(void)

{

    staticclass.anotherfunction();

}

The Parts of the I/O Kit

Physically and electronically, the I/O Kit is composed of many parts: frameworks and libraries, development and testing tools, and informational resources such as example projects, documentation, and header files. This section catalogs these parts and indicates where they are installed and how they can be accessed.

Should You Program in the Kernel?

If you are thinking of writing code for the kernel environment, think carefully. Programming in the kernel can be a difficult and dangerous task. And often there is a way to accomplish what you want to do without touching the kernel.

Software that resides in the kernel tends to be expensive. Kernel code is “wired” into physical memory and thus cannot be paged out by the virtual memory system. As more code is put into the kernel, less physical memory is available to user-space processes. Consequently, paging activity will probably intensify, thereby degrading system performance.

Kernel code is also inherently destabilizing, much more so than application code. The kernel environment is a single process, and this means that there is no memory protection between your driver and anything else in the kernel. Access memory in the wrong place and the entire system can grind to a halt, a victim of a kernel panic.

Moreover, because kernel code usually provides services to numerous user-space clients, any inefficiencies in the code can be propagated to those clients, thereby affecting the system globally.

Finally, kernel software is a real pain to write. There are subtleties to grapple with that are unknown in the realm of application development. And bugs in kernel code are harder to find than in user-space software.

With all this in mind, the message is clear. It is in everyone's best interest to put as little code as possible into the kernel. And any code that ends up in the kernel should be honed and rigorously tested.