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).

Interfaces

Fundamental Types

The UDI environment provides utility functions & types.

The fundamental types given by UDI are -

Specific-length Types

The Uniform Driver Interface declares specific-length types for use in arithmetic and logical operations. They have fixed lengths that don't change between different platforms.

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.

Abstract Types

These are integral types whose size is defined by the implementation. By keeping the size of these types abstract, the Uniform Driver Interface is able to maintain source portability between different platforms and also allow drivers to adapt to newer architectures. Specifically, for binary portability, their size is defined by the corresponding ABI specification.

Size Type

This type is used for referring to the size to any buffer or object. It can also store offsets in buffers and memory itself. It is flexible and can represent different ranges in different domains which means that its size can change between different domains. That is why it is a non-transferable variable across domain boundaries.

It must have at least 16 bits in size, for following guidelines.

typedef <INTEGRAL TYPE> udi_size_t;

Index Type

This is used by the driver to access indices of object stored in an array. It holds values in the range 0 to 255 (is zero-based) for the driver. As indices to environment object are global for the driver, it is transferable across domain boundaries.

I think is type need not have a 1 byte size as the UDI environment may encrypt the index to hide it from the driver (information presented in this statement is not guaranteed).

typedef <INTEGRAL TYPE> udi_index_t;

i) Control Block Index

The index type can be used to refer to a control that was registered through udi_cb_init_t structure. It can be used for allocating control blocks and getting hold of scratch space sizes and configuring other properties of UDI control blocks.

Note that zero is a invalid value currently, and is reserved for future usage.

ii) Metalanguage Index

The index type can also be used for holding metalanguage indices. It can be used for figuring out the metalanguages used by a driver. These indexes as associated with meta declarations in Static Driver Properties. These are of importance while the UDI Build System compiles and bundles the drivers.

iii) Ops Index

It can also be used to point to a channel operations vector by using the udi_ops_init_t function. It can be used to anchor channels and set default channel types by the driver.

Zero is a reserved value here also, and is booked for future usage.

iv) Region Index

A region-index is used to refer to a driver-defined region and is used for manipulating attributes of regions created by or on behalf of the driver instance.

The zero value refers to the primary region of the driver while other values refer to secondary regions.

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.

Each opaque handle type will have a corresponding null value. It is used for referring to null objects that don't really exist. This value need not be zero and thus the UDI_HANDLE_IS_NULL macro is provided for testing whether the handle carries a null value. null handles are not to be passed to service calls and will be treated as invalid operands. Also, the driver should never expect to receive a null value from a returning service call.

These handles may or may not be transferable depending on the object being referred to.

Channels & udi_channel_t

File -

#include "udi.h"

Declaration -

typedef <HANDLE> udi_channel_t;

NullHandle -

#define UDI_NULL_CHANNEL <NULL HANDLE VALUE>

udi_channel_t is used to refer to UDI Channels (described on another page) and are transferrable opaque handles. They are used for bi-directional communication between different drivers and with the environment.

Buffer Path Routing Handle & udi_buf_path_t

File -

#include "udi.h"

Declaration -

typedef <HANDLE> udi_buf_path_t

NullHandle -

#define UDI_NULL_BUF_PATH <NULL HANDLE VALUE>

All UDI buffers are associated with buffer path handles. They indicate destinations for incoming data and are explicitly allocated by the driver. They are not transferable between regions.