Writing I/O Kit Families

Until now we have looked at how to implement various forms of drivers, most of which interact with one or more family. In some circumstances, you may want to implement a family instead of a driver—for example, if you need to support a new bus technology or have a family of hardware devices that all depend on the same infrastructure or general services. A family can be characterized and differentiated from a driver by the following traits:

• A family usually consists of more than one IOService classes bundled together in a KEXT providing related services.
• A family can be thought of as the kernel analog of a user space shared library.
• A driver has a dependency on a family, not the other way around.
• A family is not loaded directly; it is loaded because a driver has expressed a dependency.
• A family does not have a matching dictionary and does not partake in either passive or active matching.
• Just like any other KEXT, a family is installed under /System/Library/Extensions.

There is no special API or approach to writing a family. It is simply done in the same way as any other driver. Apple recommends focusing on a good fundamental object-oriented design and allowing it to evolve naturally, rather than specifically setting out to create a family. A driver can express a dependency on a family (or any other KEXT) using the OSBundleLibraries key in its property list file. A driver cannot be loaded and linked into the kernel until all dependencies have been resolved and loaded first. The kextd daemon is responsible for performing this task. When a driver needs to be loaded, the kextd daemon will examine the driver's Info.plist file for its dependencies. If the Info.plist has incorrectly specified or has failed to list some dependencies, this will result in a link failure and the driver will not be loaded. In order to depend on a family, a driver has to list the family's bundle ID—for example, com.apple.iokit.IOAudioFamily—and version number—for example, 1.7.9fc8.

I/O Kit guarantees that a dependent family is loaded before the driver that depends on it, which is necessary, otherwise symbols in the driver would be left unresolved.

Since many of Apple's I/O Kit families are open-source code, it is possible to modify the families and replace the original versions with modified version. This is not recommended, however, as the family KEXT might be overwritten by a subsequent software update from Apple, which means that functionality of the modified KEXT might be lost. In some situations, modifying a family by inserting additional tracing might help you with debugging.

Extending a family is a better option than modifying it directly. Extending is easy, since most classes in I/O Kit families declare their methods as virtual, even if the class itself is non-abstract. There are many reasons why you might wish to do so. For example, if you were required to support a new type of USB controller not supported by the IOUSBFamily, you could create your own IOUSBController subclass to represent the new controller. The extended class can be compiled into the same KEXT as the driver that needs it, or in your own library/family KEXT. The IONetworkingFamily and other families were designed specifically to allow this form of extension.