Common-driver-library architecture supports, maintains products: USING A CDL-BASED ARCHITECTURE FOR DEVICE DRIVERS CAN SIGNIFICANTLY REDUCE THE TIME TO DEVELOP, MAINTAIN, VALIDATE, AND SUPPORT DEVICE DRIVERS FOR MULTIPLE PLATFORMS

摘要

With the plethora of operating systems available, a common problem for an independent hardware vendor is how to develop, maintain, and support device drivers for products. Although using a CDL (common driver library) can apply to any OS, the storage-device-driver example in this article focuses on Linux and Microsoft Windows. To make a CDL design work, a device-driver designer must understand and compartmentalize the typical driver functions into OS-specific and OS-agnostic functions. In this schema, the designer partitions a device driver into two logical sections based on its dependence on the operating system. Most of the driver code resides in the CDL, which essentially contains the hardware-specific function of the firmware interface, and it is OS-agnostic. The other section of the device-driver code acts as the glue that ties the common portion to an OS. The OS-dependent portion further divides into the CDHI (common-driver-host-interface) and CDHS (common-driver-host-services) layers (Figure 1).