Object Relationship

As we have seen, there are two important classes for an I/O Kit driver, one being the superclass that the main driver class inherits from and the other being the provider class that the driver uses to access its hardware. This design means that the functionality that the driver implements is separate from the way in which the driver's hardware device connects to the computer. For example, a driver that supports a PCI sound card and a driver that supports a USB audio output device will both inherit from the same IOAudioDevice superclass, and the operating system will interface to both drivers by making the same calls to each driver. After all, the operating system's audio subsystem shouldn't need to care how an audio output device connects to the computer.

This separation also encourages code reuse. A company that manufactures both PCI and USB based audio devices could potentially use the same driver for both devices, with the driver receiving a provider class that is of type IOPCIDevice or IOUSBDevice, depending on which of the two hardware devices is connected to the computer. Or, perhaps more conceivably, the hardware vendor could create its own superclass that implements the common functionality for both devices, which is itself a subclass of IOAudioDevice. The driver for the vendor's PCI and USB devices would need only a minimal implementation, with much of the common functionality coming from their custom superclass. Such an arrangement is shown in Figure 4-1.

Figure 4-1. An example of the relationship between an I/O Kit driver and its superclass and provider class