|
|
| |
|
|
|
27.1 Overview
This section defines the Metalanguage-to-Environment Interfaces (MEI) available to implementors of UDI metalanguage libraries. The use of these interfaces (as opposed to using system-specific interfaces) is necessary to create portable metalanguage libraries, to allow for the dynamic loading and unloading of metalanguage libraries (initialization interfaces), and to allow for multi-domain I/O environments distributed across heterogeneous nodes.
MEI Services must not be used directly by driver modules.
This chapter defines requirements for the design of new metalanguages.
27.2 Requirements on Metalanguage Specifications
27.2.1 General Requirements & Conventions
A UDI metalanguage specification must define a version number for all its functions and structures. A driver that confoms to and uses that metalanguage must include the appropriate "requires" versioning declaration in its udiprops.txt file (see Chapter 30, "Static Driver Properties").
In each UDI driver source file, before including any metalanguage-specific header files, the driver must define a preprocessor symbol to indicate the version of each metalanguage to which it conforms. This version number must be the same as the "requires" version number defined above. Metalanguage-specific header files must be included after "udi.h".
A portable implementation of any Metalanguage Library must include a corresponding "provides" declaration in its udiprops.txt file and must also define the preprocessor symbol.
As described in Section 30.4.6, "Requires Declaration", the two least-significant hexadecimal digits of the interface version represent the minor number; the rest of the hex digits represent the major number. Versions that have the same "major version number" as an earlier version shall be backward compatible with that earlier version (i.e. a strict superset).
27.2.2 Bindings to the Core Specification
Each metalanguage definition must specify how each of the following generic concepts apply specifically to that metalanguage.
27.2.2.1 Bindings for Static Driver Properties
Each metalanguage definition must specify the relevant interface name(s) (i.e., the <interface_name> parameter on the "requires" and "provides" and "meta" property declarations), and the definition of the interface version number for this version of this metalanguage.
Each metalanguage definition must also specify the string to use for the "category" declaration.
27.2.2.2 Bindings for Instance Attributes
Each metalanguage can specify a list of instance attributes appropriate to that metalanguage. There are four principle classes of driver instance attributes: instance-private attributes, enumeration attributes; sibling-group attributes, and parent-visible attributes. Of these, metalanguages typically specify enumeration and, in some cases, parent-visible attributes.
There are four generic enumeration attributes whose specific content must be defined for each metalanguage that can be used between drivers: "identifier", "address_locator", "physical_locator" and "physical_label".
See Section 15.2, "Instance Attribute Names" for more details on Instance Attributes.
27.2.2.3 Bindings for Custom Parameters
Many metalanguages also specify minimum requirements for driver's use of "custom" parameters by defining a set of private instance attributes each driver must support.
27.2.2.4 Bindings for Trace Events
Each metalanguage must specify how the metalanguage-selectable trace events apply to that metalanguage. This must include a definition of the metalanguage-specific semantics for UDI_TREVENT_IO_SCHEDULED and UDI_TREVENT_IO_COMPLETED, as well as any metalanguage-specific events. See Section 17.2.3, "Trace Event Types".
27.2.2.5 Abortable Ops
Each metalanguage must specify which (if any) of its metalanguage operations are abortable (see udi_channel_op_abort). By default, any operation that is not explicitly identified as abortable may be assumed to not be abortable.
Metalanguage design rule: Operations on the responder driver that can be terminated by the initiator driver after having been sent to the responder must be abortable with udi_channel_op_abort. Other metalanguage operations should not be abortable.
Any operations that are to be timed out by the initiator must be abortable with udi_channel_op_abort.
27.2.2.6 Recoverable Ops
Each metalanguage must specify which (if any) of its metalanguage operations are recoverable (see Section 4.10, "Driver Faults/Recovery"). By default, any operation that is not explicitly identified as recoverable may be assumed to not be recoverable.
Generally, operations that may need to be retried or have results passed back to another level of driver should be made recoverable. Operations that carry no payload (i.e. buffers or movable memory) and for which only one such operation can be outstanding at a time on a given channel need not be recoverable.
27.2.3 Operation Ordering Requirements
Each metalanguage must specify which operations, if any, have any ordering requirements in the handling of those operations. Due to the asynchronous nature of service call callbacks and multi-channel regions, it is possible for operations to be forwarded or completed in a different order than they are received; if this is not valid for one or more of the operations defined by the metalanguage, the metalanguage must state the explicit requirements for those operations and the driver is required to maintain the synchronization specified by the metalanguage.
The metalanguage specification must not alter the channel delivery sequencing for operations; all operations are delivered across a channel in FIFO order in all cases.
27.2.4 State Diagram
Each metalanguage should include a state diagram which indicates the valid set of state transitions for a driver implementing that metalanguage, as well as the valid set of operations for each state.
| |
|
|
|