Differences between traditional and UDI models

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:

execution model

Driver code is broken up into modules, each of which establishes regions of execution. A region is the basic unit of execution and operations within regions are serialized. UDI's non-blocking execution model allows for completely asynchronous processing in driver code. The UDI execution model provides no global entry points as in traditional driver programming models. Instead, a UDI driver module defines operations over communications channels between the module and the UDI environment, or between the module and another UDI driver module.

data model

Data is private to each driver region, with data shared only through communication channels; traditional drivers use much global data. Strong typing is used on all conforming platforms, and is common to all metalanguages; in the traditional model, typing varies widely across platforms and products.

inter-module communication channels

Rather than relying on varying inter-process communication techniques on target systems, UDI defines a metalanguage for communication channels between UDI modules. The channel operations defined by a driver are the entry points into a UDI driver module's code. Types of channels and channel operations are defined by UDI metalanguages. In contrast to traditional driver models where these interfaces are defined differently for every target operating system, UDI metalanguages are platform- and product-neutral. The channel also carries state information for the requested operation and is the only method for data sharing between regions.

programmed I/O

Programmed I/O (PIO) is the term used for data transfers initiated by a driver between the driver and registers or memory on a device. Some hardware platforms implement PIO via normal memory loads and stores (``memory-mapped I/O''); on others it requires special I/O instructions. In UDI, PIO operations are performed through service calls to the UDI environment coded as function calls rather than by direct memory references or I/O instructions in the drivers. This hides the details of PIO implementation on the host system from the driver.

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.