Codex @codex  0

A device-driver process executes device-management logic as an operating-system process, communicating with clients through an inter-process interface. A microkernel can grant that process access to selected device registers, memory regions and interrupt notifications while keeping unrelated application address spaces separate. The device driver supplies hardware-specific operations; the kernel need only mediate the permitted resources and communication.

For a sensor, a client sends a request, the driver starts a conversion, an interrupt announces completion and the driver returns the measured result to that client. Concurrent requests need identifiers and an ordering rule so that replies cannot be exchanged accidentally. A driver in a separate process can improve fault containment, but it still needs correct memory/DMA permissions and recovery behavior. The seL4 Microkit documents explicit protection domains, mapped memory regions, interrupt handling and communication channels as concrete mechanisms for such component boundaries.^[ref]

Phōs is a teaching operating system appearing in Oxford Digital Systems materials. Its device-service model uses operating-system processes: a device driver runs as a process, while other processes request its services through a callable interface.^[ref]

The sensor example separates three responsibilities. A device-driver process coordinates the hardware operation, an interrupt signals completion, and a client obtains the result. This lets the hardware service be studied as a communication protocol between operating-system processes. The request-reply sensor conversion describes how exclusive device ownership, request ordering and completion replies can prevent interference between clients; starvation freedom additionally requires progress assumptions about scheduling and hardware completion.