Drivers

This section describes different STREAMS device drivers.

At the interface to hardware devices, character I/O drivers have interrupt entry points; at the system interface, those same drivers generally have direct entry points (routines) to process open, close, read, and write subroutines, and ioctl operations.

STREAMS device drivers have similar interrupt entry points at the hardware device interface and have direct entry points only for the open and close subroutines. These entry points are accessed using STREAMS, and the call formats differ from character device drivers. The put procedure is a driver's third entry point, but it is a message (not system) interface. The stream head translates write subroutines and ioctl operations into messages and sends them downstream to be processed by the driver's write QUEUE put procedure. The read subroutine is seen directly only by the stream head, which contains the functions required to process subroutines. A driver does not know about system interfaces other than the open and close subroutines, but it can detect the absence of a read subroutine indirectly if flow control propagates from the stream head to the driver and affects the driver's ability to send messages upstream.

For input processing, when the driver is ready to send data or other information to a user process, it does not wake up the process. It prepares a message and sends it to the read QUEUE of the appropriate (minor device) stream. The driver's open routine generally stores the QUEUE address corresponding to this stream.

For output processing, the driver receives messages from the stream head instead of processing a write subroutine. If a message cannot be sent immediately to the hardware, it may be stored on the driver's write message queue. Subsequent output interrupts can remove messages from this queue.

Drivers and modules can pass signals, error codes, and return values to processes by using message types provided for that purpose.