|
|
In a traditional device driver programming model, device driver code uses facilities provided by the operating system to access intenal OS data structures and OS functions (sometimes called "system calls"). In this model, driver code will typically also use intimate knowledge of the internals of a specific device to implement common operations.
Drivers access operating system services and data structures and provide information back to the operating system through a set of interfaces documented as part of the operating system. Every operating system has a different set of interfaces (though some are similar).
These sets of interfaces taken as a whole across the industry vary widely enough that a new implementation of a particular driver is required for each OS vendor's product line and, within each product line, usually for each new version of the product.
UDI provides one set of interfaces per device type that applies across all operating systems that implement a UDI-compliant environment. See the UDI Environment Implementer's Guide for details.
In defining a model that accomplishes the goals of the UDI effort, it was necessary to make adjustments to the traditional operating system and device driver programming model.
The differences between the traditional and UDI programming models show up primarily in the definition of the UDI environment on a target operating system and in the design of the UDI metalanguage components. Among the most important differences in the UDI environment:
The UDI Environment on a target system provides a standard interface to system services that might be used by any driver type. For each UDI driver type, UDI employs a metalanguage that provides a consistent interface for that type.
The UDI Core Specification defines basic services common to all driver types, such as driver instantiation, generic input/output, inter-module communication, buffer management, utility functions, and so on.
The UDI Physical I/O Specification defines the interface between the driver and the device itself, usually over an I/O bus or bridge. The manner in which registers on the physical device are accessed is defined, as well as interrupt servicing and direct memeory access. Any definitions that are specific to a particular type oif bus are enumerated in a bus-sepcific document, such as the UDI PCI Bus Binding Specification for the PCI bus.
Building on the foundation of the above documents, the Network Driver Specification and the UDI SCSI Specification define metalanguages and bindings for UDI network adapter drivers and SCSI host bus adapter drivers, respectively.
This modular approach allows new specifications to be added to UDI as they are accommodated in the UDI environment.