Chapter 7. Communications I/O Subsystem

The Communication I/O Subsystem design introduces a more efficient, streamlined approach to attaching data link control (DLC) processes to communication and LAN adapters.

The Communication I/O Subsystem consists of one or more physical device handlers (PDHs) that control various communication adapters. The interface to the physical device handlers can support any number of processes, the limit being device-dependent.

Note: A PDH, as used for the Communications I/O, provides both the device head role for interfacing to users, and the device handler role for performing I/O to the device.

A communications PDH is a special type of multiplexed character device driver. Information common to all communications device handlers is discussed here. Additionally, individual communications PDHs have their own adapter-specific sets of information. Refer to the following to learn more about the adapter types:

• Generic Data Link Control (GDLC) Environment Overview
• MPQP Device Handler Interface Overview
• Serial Optical Link Device Handler Overview

Each adapter type requires a device driver. Each PDH can support one or more adapters of the same type.

There are two interfaces a user can use to access a PDH. One is from a user-mode process (application space), and the other is from a kernel-mode process (within the kernel).

User-Mode Interface to a Communications PDH

The user-mode process uses system calls (open, close, select, poll, ioctl, read, write) to interface to the PDH to send or receive data. The poll or select subroutine notifies a user-mode process of available receive data, available transmit, and status and exception conditions.

Kernel-Mode Interface to a Communications PDH

The kernel-mode interface to a communications PDH differs from the interface supported for a user-mode process in the following ways:

• Kernel services are used instead of system calls. This means that, for example, the fp_open kernel service is used instead of the open subroutine. The same holds true for the fp_close, fp_ioctl, and fp_write kernel services.
• The ddread entry point, ddselect entry point, and CIO_GET_STAT (Get Status) ddioctl operation are not supported in kernel mode. Instead, kernel-mode processes specify at open time the addresses of their own procedures for handling receive data available, transmit available and status or exception conditions. The PDH directly calls the appropriate procedure, whenever that condition arises. These kernel procedures must execute and return quickly since they are executing within the priority of the PDH.
• The ddwrite operation for a kernel-mode process differs from a user-mode process in that there are two ways to issue a ddwrite operation to transmit data:
  • Transmit each buffer of data with the fp_write kernel service.
  • Use the fast write operation, which allows the user to directly call the ddwrite operation (no context switching) for each buffer of data to be transmitted. This operation helps increase the performance of transmitted data. A fp_ioctl (CIO_GET_FASTWRT) kernel service call obtains the functional address of the write function. This address is used on all subsequent write function calls. Support of the fast write operation is optional for each device.

Related Information

Status Blocks for Communications Device Handlers Overview.

Communications Physical Device Handler Model Overview.

MPQP Device Handler Interface Overview.

Serial Optical Link Device Handler Overview.

Logical File System Kernel Services.

CDLI Device Drivers

Some device drivers have a different design and use the services known as Common Data Link Interface (CDLI). The following are device drivers that use CDLI:

• Forum-Compliant ATM LAN Emulation Device Driver
• Fiber Distributed Data Interface (FDDI) Device Driver
• High-Performance (8fc8) Token-Ring Device Driver
• High-Performance (8fa2) Token-Ring Device Driver
• Ethernet High-Performance LAN Adapter, Integrated Ethernet, and PCI Ethernet Device Drivers