UDI Environment

Introduction

The UDI Environment is described, by the definition in the real documentation, as a description and its corresponding implementation of all interfaces provided to UDI-compliant drivers which include the system services, implicit scheduling and synchronization, and inter-module communication infrastructure. The environment is the means by which the Uniform Driver Interface provides a software and hardware independent nature to its drivers. The UDI specs provide a complete environment for the development of compliant driver.

The drivers use the services of the UDI environment by service calls. These are implemented as functions which are exported to all UDI driver instances. This makes them common to all UDI drivers. The environment must provide two types of service calls - asynchronous and synchronous.

Development

UDI environments are generally tied to the OS and are more platform-dependent. They can be developed by looking into the UDI specifications. The UDI environment must implement some core services and utility functions. For source code compatibility, the interface must be compacted into two header files - udi.h and udi_physio.h (see Physical I/O Specifications).

Utility Functions

Fundamental Types

The UDI environment provides utility functions & types. The fundamental types given by UDI are -

1. typedef unsigned char udi_ubit8_t

2. typedef unsigned short udi_ubit16_t

3. typedef unsigned int udi_ubit32_t

4. typedef char udi_sbit8_t

5. typedef short udi_sbit16_t

6. typedef int udi_sbit32_t

7. typedef udi_ubit8_t udi_boolean_t

Driver must use these types at least while passing arguments and returning variables. They can internally use the ISO C types because that doesn't affect compatibility. For example, the long type is useful for getting the most optimized type for the architecture.

Opaque Types

These types are not for direct access by drivers. They are essentially handles (like in Windows NT, just relating man) which are passed to service calls to refer to actual objects. They are used to protect system data and prevent malicious code from corrupt valuable data. The size of these handles are specified in the ABI bindings, so these handles have the size of long on IA32/64 architectures. A rather simple implementation will use just the address of the object in the handle. But for better security, determined projects could use a value that is the result of the operation between the ID given to a UDI driver and a index into a handle table. After undoing the effect of that operation, the environment will get the address of the object by accessing a handle table.