Character I/O Architecture

This chapter describes:

Overview

At present, each character driver is a separate process. Each driver links against the libio-char.a library:


Current architecture


Current character I/O architecture.

Most of our character device drivers are single-threaded, but read and write requests don't block each other.

When a read request comes in, the io-char library looks at its input buffers (either edited or raw, depending on the mode of the file descriptor being read on), and if there's enough data to satisfy the request, calls MsgReply() to reply to it, and then continues. If there isn't enough data or there's already a read in progress, the request gets put on a pending read list and the driver goes back to MsgReceive() to service other requests. Once the hardware has provided enough data to satisfy the read (which the driver knows because of receive-data interrupts), the pending request gets pulled off the list and replied to.

When a write request comes in, the driver dumps as much data as it can into the output buffer, and if there's still more left, puts the request on a pending write list. As the hardware transfers the characters in the output buffer out, more are copied from the write request until all are gone. At that point, the driver calls MsgReply() to reply to the write.

Because of the pending read/write lists, the driver never blocks on the hardware; it's always back at the MsgReceive() and available to service other clients.

DDK source code

When you install the DDK package, the source is put into a directory under the ddk_install_dir ddk-char directory. Currently, the directory structure for the Character DDK looks like this:


Character DDK directories


Directory structure for the Character DDK.