The LDD/PDD Model

Device driver DLLs come in two types - the logical device driver (LDD), and the physical device driver (PDD). Typically, a single LDD supports functionality common to a class of hardware devices, whereas a PDD supports a specific member of that class. This means that the generic code in the LDD only needs to be written once, and the same user-side API can be used for all variants of a device.

Many PDDs may be associated with a single LDD. For example, there is a single serial communications LDD (ECOMM.LDD) which is used with all UARTs. This LDD provides buffering and flow control functions that are required with all types of UART. On a particular hardware platform, this LDD will be accompanied by one or more PDDs, which support the different types of UART present. A single PDD can support more than one UART of the same type; separate PDDs are only required for UARTs with different programming interfaces. Typically, the PDD is kept as small as possible.

Only LDDs communicate with user-side code; PDDs communicate only with the corresponding LDD, with the variant or kernel extensions, and with the hardware itself. Device drivers provide their interface for user side applications by implementing a class derived from the Kernel API RBusLogicalChannel. The functions of the derived class form a thin layer over the functions defined in RBusLogicalChannel and are commonly implemented inline and published in a header file. However, if the API functions need to do more complex tasks, then they can be implemented in their own DLL. The kernel also provides a API RDevice, which enables user side code to get information about a device.

The following diagram shows the general idea:

To make porting to particular hardware platforms easier, some drivers make a further logical split in their PDD code between a platform-independent layer (PIL), which contains code that is common to all the hardware platforms that the driver could be deployed on, and a platform-specific layer (PSL), which contains code such as the reading and writing of hardware-specific registers.

Depending on the device or the type of device to access, this split between LDD and PDD may not be necessary; the device driver may simply consist of an LDD alone.