|
|
| |
|
|
|
3.1 Introduction
This chapter defines common terminology used in the UDI Core Specification. There are two categories of terminology defined here: terms whose purpose is to provide directives on the behavior, features and semantics of the UDI Specification, called directive terms; and common terms that are not UDI-specific. This chapter clarifies how these terms are used in this Specification.
UDI architectural terms and other UDI-specific terms are defined in the Glossary in Appendix A.
3.2 Definitions
3.2.1 Directive Terms
These terms provide directives on the behavior, features, and semantics of the UDI Core Specification. Other UDI specifications are encouraged to reference and use these directive terms for consistency with the Core Specification, but may choose to define their own set of directive terms (e.g., for consistency with a related hardware standard).
can indicates that the existence of a particular feature or behavior of a UDI driver is optional; UDI drivers may choose whether or not to use the feature or behavior.
ignored indicates that the contents of a particular field cannot be usefully examined; UDI drivers must not examine such fields.
illegal indicates a violation of the Specification. The consequences of illegal actions on the part of a UDI driver are implementation dependent, and may include abrupt termination of the driver or catastrophic system failure.
implementation-dependent indicates that a particular feature or behavior is not consistent across all environment implementations and must not be relied upon by UDI drivers.
invalid indicates a condition which is not valid within a given context.
may indicates that the existence of a particular feature or behavior of the UDI environment is optional; UDI drivers must not rely on the existence of the feature or behavior. To avoid ambiguity, the antonym of may is expressed as need not, instead of may not.
must indicates a requirement on a UDI driver.
shall indicates that the feature or behavior described is a requirement on the UDI environment; UDI drivers can rely on the existence of the feature or behavior.
should indicates that a feature or behavior is strongly recommended but not mandatory.
unspecified indicates that the contents of a particular field are not consistent across all environment implementations and must not be relied upon by UDI drivers.
3.2.2 Common Terms
The following are terms which are commonly used in the industry in a manner similar to the usage in this Specification; these definitions clarify how these terms are used in this Specification. Other UDI specifications are encouraged to reference and use these definitions for consistency with the UDI Core Specification.
adapter I/O hardware which provides a specific function or connectivity/bridging capability and which is accessed via a system bus. Also called a card, a controller, a NIC, or an HBA. The adapter is typically accessed via programmed I/O and may be capable of generating interrupts or DMA activity (or be capable of being a DMA target).
adapter driver device driver software responsible for managing an adapter.
address domain an address space wherein the same address always refers to the same memory object. Two software modules are in different address domains if the same address does not refer to the same memory when used in each module, or if an address that is accessible to one is not accessible to the other. Thus, it is useless to pass an address across domains. Whenever information is passed across a domain boundary, all pointers must be converted, either by copying the information to which they point or by remapping the same physical memory to a new virtual address.
ABI Architected Binary Interface. This is a set of binary bindings for a programming interface specification such as the UDI Core Specification. (When applied to applications rather than system programming interfaces, ABI is usually interpreted as Application Binary Interface.)
API Architected Programming Interface. This is a programming interface defined in a UDI specification; e.g., a function call interface or structure definition with associated status or function codes, as well as associated semantics and rules on the use of the interfaces. (When applied to applications rather than system programming interfaces, API is usually interpreted as Application Programming Interface.)
ANSI American National Standards Institute. ANSI is a United States national standards body, and is the sole U.S. representative and dues-paying member of the two major non-treaty international standards organizations, the International Organization for Standardization (ISO), and, via the U.S. National Committee (USNC), the International Electrotechnical Commission (IEC).
big endian data storage format in which a multi-byte data value is stored with the most-significant data byte through least-significant data byte in the lowest through highest byte addresses, respectively. This is the storage format traditionally used by the Motorola 680x0, HP PA-RISC, Sun SPARC, and AMD 29000-series processors.
blocking the process of suspending a thread of execution until an event occurs, possibly switching to other threads in the meanwhile. To the programmer, this appears to be a procedure call that may not return for a long and indeterminate amount of time. Also known as sleeping. Can also be used as an adjective describing OS service calls that can cause such a suspension.
UDI uses asynchronous service calls instead of blocking service calls, so there is no way for a UDI-compliant driver to block. Note that this does not affect the embedding OS and its users' applications, since native synchronous or asynchronous operations are supported by external mapper implementations independently of the UDI drivers.
byte A unit of data storage made up of eight binary digits (bits). An octet. UDI does not use the archaic meaning of "byte" to refer to anything other than 8-bit data units.
capability domain see protection domain.
ccNUMA Cache Coherent Non-Uniform Memory Access, an architecture for highly parallel systems with shared memory of varying latencies.
data encapsulation a method of maintaining the functional independence of separately designed and/or compiled code modules by hiding all the data relevant to a module in an abstract object that may only be manipulated by calls to the module itself.
device physical hardware, under software control, which is typically attached either directly to an I/O bus or to an auxiliary bus (e.g. SCSI) attached to a directly-connected adapter. The device typically combines a hardware controller with the raw mechanism (disk controller with disk, display controller with frame buffer, etc.).
device driver a software module that turns I/O requests into control of a specific physical device or a hardware or protocol interface. A device driver contains all the device-specific code necessary to control and communicate with its hardware or logical function and provides a standard interface to the rest of the system. A driver may or may not control "raw" hardware.
device endianness the endianness of the device's accesses to memory (typically either its own memory or system memory).
device ID a numeric or string value with a device-interconnect specified format used to provide device identification. Usually stored in I/O card ROM.
device instance an instance of a physical device, such as an adapter, or a pseudo-device. A single UDI driver may manage multiple device instances, however, UDI implements instance independence which makes these multiple device instances invisible to each other.
device model a semantic model for accessing and controlling a particular class of I/O device, such as SCSI or Network.
device node a node in the device tree.
device tree an abstract data structure that represents the physical and logical topology of an I/O system. This data structure is usually thought of as an n-ary tree structure, but can occasionally have multiple parents for the same node, so is really an acyclic directed graph. Even with multiple parents, however, the graph ultimately has a single root. Each node represents a device instance.
domain A physical or logical area that shares some common characteristic. See address domain and protection domain.
driver endianness the endianness of the driver's accesses to its data. This is sometimes referred to as the endianness of the driver's region.
driver instance a set of one or more regions, all belonging to the same driver, that are associated with a particular instance of the driver's device. There may be multiple instances of a given driver, one for each physical device controlled or (in the case of software-only drivers) one for each logically-separate replication of a function. Each active device node has exactly one corresponding driver instance.
embedding system the surrounding Operating System in which the UDI environment is contained.
endianness see driver endianness, device endianness, protocol_endianness
entry point a function within a driver that is called from outside that driver.
environment the UDI Environment: a description of all interfaces surrounding the driver and the implementation thereof. Includes system services, scheduling and synchronization, as well as inter-module communication mechanisms.
handle an opaque reference to an environment object that must not be directly referenced by drivers. See the UDI architectural definition of handle, transferable handle and nontransferable handle in the Glossary.
HBA Host Bus Adapter. Another name for an adapter, but most commonly used for SCSI adapters.
informative provides information, guidance, instruction. Informative documentation describes, instructs, and provides guidance on the use of required interfaces, but does not define those requirements; normative documentation defines the requirements. See also normative.
instance a single, logically separate replication (associated with a thread of execution, not a physical copy of code) of a module along with its associated data, methods and services (see "driver instance").
IEC International Electrotechnical Commission.
IETF Internet Engineering Task Force.
ISA 1) Instruction Set Architecture. Defines the binary machine language syntax and semantics for a particular type of processor or processor family.
2) Industry Standard Architecture. An I/O bus type originally designed for the IBM AT and used in many PCs. Also known as the ATA bus.
ISO International Organization for Standardization. ISO is a worldwide federation of national standards bodies from some 130 countries, one from each country. Note that ISO is not an acronym, but is an international term used to refer to the International Organization for Standardization independent of national language, and is derived from the Greek word meaning "equal".
little endian data storage format in which a multi-byte data value is stored with the least-significant data byte through most-significant data byte in the lowest through highest byte addresses, respectively. This is the storage format used by Intel and Digital processors.
natural alignment alignment of a field in a structure on a boundary (offset) within the structure which is a multiple of the size of the field's data type. Thus, a naturally aligned 1 byte field begins on a byte boundary; a naturally aligned 2 byte field on a 2 byte boundary, etc.
non-blocking an interface or execution model which does not require blocking (see blocking).
normative establishes a standard or norm. Normative documentation defines required interfaces and semantics. Often the term normative is used in juxtaposition to the term informative. E.g., the UDI Specifications are normative; the UDI white papers and implementation guides are informative.
object an instance of a data structure, encapsulating a logical instance of a software function, that is operated on with specific, defined function calls.
opaque type a type of data object whose fields are not visible to drivers, used in defining UDI data structures and handles.
Operating System the primary code executing on a hardware platform which is responsible for managing that platform and providing the environment under which applications may be run on that platform.
platform the overall system that embeds UDI, consisting of all the hardware, together with the native operating system.
protection domain (also called "capability domain"): a collection of software which shares the same memory access protection level (e.g. kernel v.s. user). When it is necessary for software running in one protection domain to invoke an operation in another domain, special provisions must be made in the environment for checking permissions and passing parameters across the domain boundary.
protocol endianness the endianness of hardware protocol data such as SCSI commands or networking protocol headers.
pseudo device a logical "device" which has no associated hardware. Pseudo-device drivers present the view of a device to their children even though they do not control an actual device. Pseudo-device instances are roots of their own device trees, separate from the hardware device tree.
SCSI Small Computer Systems Interface, a standard storage architecture and protocol.
thread an instance of execution consisting of a procedure stack and OS scheduling structures. A thread, together with an address space and permissions, is equivalent to a traditional "process". On multiprocessor systems, multiple threads execute simultaneously.
trusted code code that the operating system is minimally suspicious of. Drivers are commonly trusted in that there are fewer run-time error checks included in the system interfaces in exchange for higher performance. UDI, however, allows for environments with low trust in drivers, and gives such environments the opportunity to do any error checking they might wish.
UDI Uniform Driver Interface. In some contexts, this is a short-hand term for the UDI environment and the entities in the embedding system that the UDI environment supports.
| |
|
|
|