Glossary

autoconfiguration

Autoconfiguration is a process that determines what hardware actually exists during the current instance of the running kernel at static configuration time.

autoconfiguration software

The autoconfiguration software consists of the programs that accomplish the tasks associated with the events that occur during the autoconfiguration of devices. In most cases, it is not necessary for device driver writers to know the specific programs that execute during autoconfiguration.

block device

A block device is a device that is designed to operate in terms of the block I/O supported by Digital UNIX. It is accessed through the buffer cache. A block device has a block device driver associated with it.

block device driver

A block device driver is a driver that performs I/O by using file system block-sized buffers from a buffer cache supplied by the kernel. Block device drivers are particularly well-suited for disk drives, the most common block devices.

boot-link

Boot-link is the software that allows a Digital UNIX system to create a kernel as a system is booting up. The boot-link software is part of the osfboot program functionality. The osfboot program invokes the boot-link software when it detects a boot-link file (instead of a binary /vmunix kernel image) or when the user specifies the appropriate flags with the console boot command.

The boot-link software allows for the delivery of hardware platform (HAL) support and the support of foreign devices (graphics, disk, and network devices) in the Digital UNIX boot path at installation time.

buffer cache

A buffer cache is supplied by the kernel and contains file system block-sized buffers. Block device drivers use these buffers in I/O operations.

buf structure

The buf structure describes arbitrary I/O, but is usually associated with block I/O and physio.

bus

A bus is a physical communication path and an access protocol between a processor and its peripherals. A bus standard, with a predefined set of logic signals, timings, and connectors, provides a means by which many types of device interfaces (controllers) can be built and easily combined within a computer system. See also OPENbus.

bus physical address

A bus physical address is an address that the device driver can pass to another device on the bus. A device driver can use a bus physical address to reference the I/O or memory space of other cards that reside on the same bus as the card that the device driver controls.

bus structure

The bus structure represents an instance of a bus entity. A bus is a real or imagined entity to which other buses or controllers are logically attached. All systems have at least one bus, the system bus, even though the bus may not actually exist physically. The term controller here refers both to devices that control slave devices (for example, disk or tape controllers) and to devices that stand alone (for example, terminal or network controllers).

bus support subsystem

The bus support subsystem contains all of the bus adapter-specific code. Isolating the bus-specific code and data structures into a bus support subsystem makes it easier for independent software vendors to implement different bus adapters.

The bus support subsystem communicates with the hardware-dependent and device driver subsystems of the hardware-independent model. See also device driver subsystem and hardware-dependent subsystem.

busy wait time

Busy wait time is the amount of CPU time expended on waiting for a simple lock to become free.

central processing unit (CPU)

The central processing unit (CPU) is the main computational unit in a computer and the one that executes instructions. The CPU is of interest to device driver writers because its associated architecture influences the design of the driver. For example, CPUs can have different mechanisms for handling memory mapping.

cfgmgr daemon

The cfgmgr daemon is a system management process that works with kloadsrv, the kernel load server, to manage device drivers that are dynamically configured into the kernel.

cfgmgr framework

The cfgmgr framework is the collection of software that allows device drivers to be produced as a single binary module that can be statically or dynamically configured into the kernel. Specifically, the cfgmgr framework supplies support for configuring a single binary module in the boot path when a kernel is booting and after single user time.

character device

A character device is any device that can have streams of characters read from or written to it. A character device has a character device driver associated with it.

character device driver

A character device driver is a driver that can use a variety of approaches to handle I/O. A character device driver can accept or supply a stream of data based on a request from a user process. You can use a character device driver for a device such as a line printer that handles one character at a time. However, character drivers are not limited to performing I/O one character at a time (despite the name ``character'' driver). For example, tape drivers frequently perform I/O in 10K chunks. You can also use a character device driver when it is necessary to copy data directly to or from a user process.

Because of their flexibility in handling I/O, many drivers are character drivers. Line printers, interactive terminals, and graphics displays are examples of devices that require character device drivers.

config program

The config program is a system management tool that doconfig calls. The config program either creates a new or modifies an existing target configuration file, copies .product.list to NAME.list, creates the device special file information for statically configured drivers, and builds a new Digital UNIX kernel.

configuration

Configuration is a process associated with handling user-level requests to the sysconfig utility to dynamically configure, unconfigure, query, and reconfigure devices. The cfgmgr framework calls the driver's configure interface as a result of these sysconfig utility requests. The cfgmgr framework also calls the driver's configure interface as a result of static configuration requests. Thus, the driver's configure interface cooperates with the cfgmgr framework to statically configure and to dynamically configure, unconfigure, query, and reconfigure devices. See also cfgmgr framework.

configure interface

A device driver's configure interface cooperates with the cfgmgr framework to handle user-level requests to dynamically configure, unconfigure, query, and reconfigure a device driver. In addition, the driver's configure interface cooperates with the cfgmgr framework to handle static configuration requests. The driver's configure interface also cooperates with the cfgmgr framework to perform one-time initialization tasks such as allocating memory, initializing data structures and variables, adding the driver's I/O services interfaces, and reserving a major number in the dsent (device switch) table. You should implement a driver's configure interface to handle static and dynamic configuration.

control status register (CSR)

See device register.

controller

A device controller is the hardware interface between the computer and a peripheral device. Sometimes a controller handles several devices. In other cases, a controller is integral to the device.

controller structure

The controller structure represents an instance of a controller entity, one that connects logically to a bus. A controller can control devices that are directly connected or can perform some other controlling operation, such as a network interface or terminal controller operation.

CPU

See central processing unit.

DCD

See direct CD.

daemon

A daemon is a system management process that controls a variety of kernel tasks.

See also cfgmgr daemon.

data structure

Data structures are the mechanism used to pass information between the Digital UNIX kernel and device driver interfaces.

dense space address

A dense space address is an address that resides in dense space. Dense space is an area of I/O space or memory space that device drivers can access as if it were memory. Not all Alpha CPUs support dense space.

See also sparse space address.

device.mth

A tool that works with dynamically configured drivers. It creates and deletes the device special files associated with dynamically configured drivers. Contrast this with the kmknod utility, which creates and deletes device special files associated with statically configured drivers.

device autoconfiguration

See autoconfiguration.

device controller

See controller.

device driver

A device driver is a software module that resides within the Digital UNIX kernel and is the software interface to a hardware device or devices. The purpose of a device driver is to handle requests made by the kernel with regard to a particular type of device. See also block device driver, character device driver, and network device driver.

device driver configuration

Device driver configuration consists of the tasks necessary to incorporate device drivers into the kernel to make them available to system management and other utilities. See also dynamic configuration and static configuration.

device driver kit

The device driver kit contains the files associated with a device driver product. These files contain information necessary for system managers (customers) to install a device driver product. A subset control program (SCP), part of the device driver kit, can request the system manager choose to statically or dynamically configure the driver.

device driver kits delivery process

The device driver kits delivery process is the mechanism for developing, delivering, installing, and configuring device drivers on systems that run Digital UNIX.

device driver subsystem

The device driver subsystem contains all of the driver-specific code. The device driver subsystem communicates with the hardware-dependent, bus support, and hardware-independent subsystems of the hardware-independent model.

See also bus support subsystem, hardware-dependent subsystem, and hardware-independent subsystem.

device register

A device register is commonly referred to as a control status register, or CSR. The device register can be used to:

• Control what a device does

• Report the status of a device

• Transfer data to or from the device

device register header file

The device register header file contains any public declarations that the device driver uses. This file usually contains the device register offset definitions associated with the device.

device register offset definition

A device register offset definition is a C #define that maps to the register of some device. Typically, you define one offset for each device register. These device registers are often referred to as the device's control status register (or CSR) addresses. The device register offset definition is usually defined in the device register header file.

device structure

The device structure represents an instance of a device entity. A device is an entity that connects to and is controlled by a controller. A device does not connect directly to a bus.

device switch table

The device switch table for block and character devices has the following characteristics:

• It is an array of dsent structures that contain device driver entry points (and other information). These entry points are actually the addresses of the specific I/O services interfaces within the drivers.

• The array can contain stubs for device driver entry points for devices that do not exist on a specific machine.

• The location in the table corresponds to the device major number.

See also dsent structure.

dev_t data type

The dev_t data type is a type definition of the major and minor device numbers. Device driver writers use the dev_t data type to represent a device's major and minor numbers. This data type is an abstraction of the internal representations of the major and minor numbers. Driver writers do not need to know how the system internally represents the major and minor numbers.

direct CD

Direct CD is a setld technology that allows kernel (device driver) kits to be delivered on a ufs file system. The boot-link software uses this technology to read control, object, and configuration information from a direct CD-formatted kit to install device drivers that support foreign devices or to install a hardware platform (HAL).

direct memory access (DMA)

Direct memory access (DMA) describes the ability of a device to directly access (read from and write to) CPU memory, without CPU intervention.

direct memory access (DMA) device

A direct memory access (DMA) device is one that can directly access (read from and write to) CPU memory, without CPU intervention. Non-DMA devices cannot directly access CPU memory.

DMA handle

Specifies a handle to DMA resources associated with the mapping of an in-memory I/O buffer onto a controller's I/O bus. This handle provides the information to access bus address/byte count pairs. A bus address/byte count pair is represented by the ba and bc members of an sg_entry structure pointer. Device driver writers can view the DMA handle as the tag to the allocated system resources needed to perform a DMA operation.

DMA

See direct memory access.

doconfig

The doconfig program is a system management tool that calls config. See config program.

driver structure

The driver structure defines driver entry points and other driver-specific information. You declare and initialize an instance of this structure in the declarations section of the device driver.

dsent structure

The dsent data structure contains pointers to entry points for a specific driver's I/O services interfaces and other information. The system maintains a table (array) of these dsent structures (referred to as the device switch table) that contains pointers to entry points for the associated driver's I/O services interfaces for each block and character mode device that the system supports.

Each entry in the table of dsent structures represents a major number for both block and character devices.

See also device switch table.

dynamic configuration

Dynamic configuration consists of the tasks and tools necessary to link a device driver (single binary module) directly into the kernel at any point in time.

dynamically configured device driver

A dynamically configured driver is one that implements the appropriate tasks in the configure interface to handle user-level requests from the sysconfig utility. A dynamically configured driver is actually a single binary module, which is an executable with a file extension of .mod. This single binary module can be dynamically linked into the kernel (that is there is no need to rebuild the kernel, shut down the system, and reboot). See also statically configured device driver.

files file

A files file contains the following information about device drivers:

• The location of the source code associated with the product drivers

• Tags indicating when the product drivers are to be loaded into the kernel

• Whether the source code or the binary form of the product drivers is supplied to the customer

foreign device

A foreign device is hardware used during the initial installation and boot of Digital UNIX.

files file fragment

You can view the files file fragment as a ``mini'' files file. That is, it contains the exact same information as the files file. The files file fragment is the mechansm that third-party driver writers use to make the information about their device driver products available to customer's systems.

GENERIC system configuration file

The Digital-supplied GENERIC configuration file is the configuration file for the all-encompassing generic kernel that is originally installed on the system. It contains all the possible software and hardware options that Digital supports. The GENERIC configuration file is used to build a kernel that represents all possible combinations of statically configured drivers that Digital supports.

handler_intr_info structure

The handler_intr_info structure contains interrupt handler information for device controllers connected to a bus. This generic structure makes device drivers more portable across different buses because it contains all of the necessary information to add an interrupt handler for any bus. Device driver writers set the ih_bus_info member of the ihandler_t structure to the filled-in handler_intr_info structure, usually in the driver's probe interface.

hardware device

See peripheral device.

hardware-dependent subsystem

The hardware-dependent subsystem contains all of the hardware-dependent pieces of an operating system with the exception of device drivers. This subsystem provides the code that supports a specific CPU platform and, therefore, is implemented by specific vendors.

The hardware-dependent subsystem communicates with the hardware-independent subsystem, device driver subsystem, and bus support subsystem of the hardware-independent model. See also bus support subsystem, device driver subsystem, and hardware independent subsystem.

hardware-independent model

The hardware-independent model describes the hardware and software components that make up an open systems environment. Specifically, these hardware and software components are contained in a hardware-independent subsystem, hardware-dependent subsystem, bus support subsystem, and device driver subsystem. See also bus support subsystem, device driver subsystem, hardware-dependent subsystem, and hardware independent subsystem.

hardware-independent subsystem

The hardware-independent subsystem contains all of the hardware-independent pieces of an operating system, including the hardware-independent kernel interfaces, user programs, shells, and utilities. This subsystem can contain extensions and enhancements made by vendor companies, including Digital Equipment Corporation.

The hardware-independent subsystem communicates with the hardware-dependent subsystem, bus support subsystem, and device driver subsystem of the hardware-independent model. See also bus support subsystem, device driver subsystem, and hardware-dependent subsystem.

ihandler_id_t key

The ihandler_id_t key is a unique number used to identify interrupt handlers to be acted on by subsequent calls to the handler_enable, handler_disable, and handler_del kernel interfaces.

ihandler_t structure

The ihandler_t structure contains information associated with device driver interrupt handling.

interrupt handler

An interrupt handler is a device driver routine that services hardware interrupts.

I/O address

An I/O address is either a sparse space or dense space address that performs an I/O cycle on a specific bus.

See also dense space address and sparse space address.

I/O handle

An I/O handle is a data entity that is of type io_handle_t. This I/O handle provides device drivers with bus address information. The bus configuration code passes the I/O handle to the device driver's probe interface during device autoconfiguration. (The bus configuration code also passes this I/O handle to the device driver's slave interface, if one is implemented, during device autoconfiguration.)

kernel

The kernel is a software entity that runs in supervisor mode and does not communicate with a device except through calls to a device driver.

kernel kit

See device driver kit.

kernel physical address

A kernel physical address is an address that resides in kernel address space but does not use the virtual memory (VM) mapping registers.

See also kernel-unmapped virtual address.

kernel-unmapped virtual address

A kernel-unmapped virtual address is an address that resides in kernel address space. This address is sometimes referred to as a kseg address. A kernel-unmapped virtual address makes use of the virtual memory (VM) mapping registers.

See also kernel physical address.

kloadsrv

The kernel loader daemon is used with the cfgmgr daemon to dynamically configure the device driver (single binary module) into the kernel address space and to resolve external references. See also cfgmgr daemon.

kmknod

The kmknod utility is a system management tool that uses the information from the driver's sysconfigtab file fragment and the driver's attribute table to dynamically create device special files at boot time for statically configured drivers.

kreg utility

The kreg utility is a system management tool that maintains the /sys/conf/.product.list system file, which registers device driver products that are statically configured into the kernel.

kseg address

See kernel-unmapped virtual address.

memory address

A memory address is either a sparse space or dense space address that performs a memory cycle on a specific bus.

See also dense space address and sparse space address.

method

A method is a subsystem specific portion of the cfgmgr framework. For example, the device method is the portion of the cfgmgr framework that supports statically and dynamically configured device drivers. See also device.mth.

module

A module is a collection of one or more objects linked together into a single entity. A module makes it possible to produce a single binary module (executable) that can be statically or dynamically configured into the kernel.

name.kit file

The name.kit file contains the information that certain hardware needs during the initial installation and boot of Digital UNIX. This hardware is referred to as a foreign device.

NAME.list file

The NAME.list file is a copy of the .product.list file that is created when the doconfig program is run without the -c option. This is typically done in the subset control program. See also .products.list file.

network device

A network device is any device associated with network activities and is responsible for both transmitting and receiving frames to and from the network medium. Network devices have network device drivers associated with them.

network device driver

A network device driver attaches a network subsystem to a network interface, prepares the network interface for operation, and governs the transmission and reception of network frames over the network interface.

OPENbus

The term OPENbus refers to those buses whose architectures and interfaces are publicly documented, allowing a vendor to easily plug in hardware and software components. The TURBOchannel bus, the EISA bus, the PCI bus, and the VMEbus, for example, can be classified as having OPENbus architectures.

open systems

The term open systems refers to an environment with hardware and software platforms that promote the use of standards. By adhering to a set of standard interfaces, these platforms make it easier for third-party programmers to write applications that can run on a variety of operating systems and hardware. This open systems environment can also make it easier for systems engineers to write device drivers for numerous peripheral devices that operate on this same variety of operating systems and hardware.

osfboot

The osfboot software is the Digital UNIX bootstrap program responsible for linking, reading, and booting a kernel. It is the osfboot software that prompts a user to specify a boot-link kernel on the console command line.

peripheral device

A peripheral device is hardware, such as a disk controller, that connects to a computer system. It can be controlled by commands from the computer and can send data to the computer and receive data from it.

port structure

The port structure contains information about a port.

postconfiguration

Postconfiguration is a process that occurs when a device driver is configured. This point in time allows the device driver to cooperate with the cfgmgr framework to perform driver-related configuration services.

For static configuration, postconfiguration involves the device driver registering a callback interface that performs the task of reserving a major number. The kmknod utility uses this major number to make the correct device special files.

For dynamic configuration, postconfiguration involves the device driver reserving a major number (typically by calling a device driver-implemented interface). The device.mth tool uses this major number to make the correct device special files.

preconfiguration

Preconfiguration is a process that occurs when a device driver is configured. This point in time allows the device driver to cooperate with the cfgmgr framework to perform driver-related configuration services.

For static configuration, preconfiguration involves the device driver registering a callback interface that performs the task of creating the driver's associated controller and device structures that the autoconfiguration software integrates into the system (hardware) configuration tree.

For dynamic configuration, preconfiguration involves the device driver's configure interface creating the driver's associated controller and device structures that the autoconfiguration software integrates into the system (hardware) configuration tree.

.product.list file

The /usr/sys/conf/.product.list file stores information about device driver products that are installed on Digital UNIX systems.

pseudodevice driver

A pseudodevice driver, such as the pty terminal driver, is structured like any other driver. The difference is that a pseudodevice driver does not operate on a bus and does not control a hardware device. A pseudodevice driver does not register itself in the hardware topology (system configuration tree). Instead, it relies on the device driver method of the cfgmgr framework to create the associated device special files.

SCP

See subset control program.

setld

The setld utility provides the transfer of the contents of the device driver kit to a customer's system on Digital UNIX.

shared interrupt handler

A shared interrupt handler is a driver routine registered to take advantage of the shared interrupt framework that Digital UNIX provides for hardware devices that share an interrupt line.

shared interrupt line

A shared interrupt line is a hardware interrupt level (connection) shared by more than one hardware device.

single binary module

A single binary module is the executable image of a device driver that can be statically or dynamically configured into the kernel. A single binary module has a file extension of .mod.

sparse space address

A sparse space address is an address that resides in sparse space. Sparse space contains addresses that reside in bus address space (either I/O space or memory space). All Alpha CPUs support sparse space. As a result, all bus configuration code should supply an I/O handle that references bus address space.

See also dense space address.

static configuration

Static configuration is the process of incorporating single binary modules (device drivers) into the kernel and making them available to system management and other utilities. A device driver must implement its configure interface to cooperate with the cfgmgr framework in handling static configuration requests.

statically configured device driver

A statically configured driver is one that implements the appropriate tasks in the configure interface to handle static configuration requests. A statically configured driver is actually a single binary module, which is an executable with a file extension of .mod. This single binary module can be statically configured into a /vmunix kernel or a /sysconfigtab kernel (referred to as the boot-link kernel). See also dynamically configured device driver.

subset control program (SCP)

A subset control program (SCP) is a program written by the kit developer that contains path specifications for all of the files related to the driver product. The SCP is invoked by setld during the installation of the device driver kit.

sysconfig

The sysconfig utility is a system management tool that configures a driver or handles a dynamically configured device driver. The sysconfig utility provides a user interface to the cfgmgr framework.

sysconfigdb

The sysconfigdb utility is a system management tool that maintains the sysconfigtab database. The driver entries in the sysconfigtab file fragment are appended to this database when the user installs a kernel kit.

sysconfigtab database

The sysconfigtab database contains the information provided in the sysconfigtab file fragments. This information is appended to the /etc/sysconfigtab database when the system manager runs the sysconfigdb utility during the installation of the device driver kit.

sysconfigtab file fragment

The sysconfigtab file fragment contains device special file information, bus option data information, and physically contiguous memory usage information for statically and dynamically configured drivers. When the user installs a kernel kit, the sysconfigtab file fragment gets appended to the /etc/sysconfigtab database.

system configuration tree

The system configuration tree represents the result of the device autoconfiguration process. The result is a correctly linked list of bus, controller, and device structures.

target configuration file

The target (system) configuration file is an ASCII text file that defines the components of the system. These components are described using valid keywords such as those that identify device definitions, callout definitions, and pseudodevice definitions.

terminal device

A terminal device is a special type of character device that can have streams of characters read from or written to it. Terminal devices have terminal (character) device drivers associated with them.

terminal device driver

A terminal device driver is actually a character device driver that handles I/O character processing for a variety of terminal devices. Like any character device, a terminal device can accept or supply a stream of data based on a request from a user process. It cannot be mounted as a file system and, therefore, does not use data caching.

uio structure

The uio structure describes I/O, either single vector or multiple vectors. Typically, device drivers do not manipulate the members of this structure.

user program

A user program is a software module that allows a user of Digital UNIX to perform some task. For example, the ls user program allows users to list the files contained in a specific directory. User programs make system calls to the kernel that result in the kernel making requests of a device driver. A user program never directly calls a device driver.

vmunix

A vmunix is a kernel image that contains the compiled and linked files (including those associated with the device driver product) that are part of this instance of the running kernel.

Alternatively, the doconfig -b command generates a text file, referred to as /sysconfigtab. (This is referred to as the boot-link kernel.) The text file contains a list of the modules to be dynamically linked to produce a kernel at boot time. This text file is generated only when there is a foreign device.

The Digital UNIX boot software determines the type of file being booted and applies the appropriate boot technology.