The Programming Interface - Operating Systems: Principles and Practice - page 115

After all, a disk device is quite different from a network and both are quite
different from a keyboard: a disk is addressed in fixed sized chunks, while a
network sends and receives a stream of variable sized packets, and the keyboard
returns individual characters as keys are pressed. While the disk only returns
data when asked, the network and keyboard provide data unprompted. Early
computer systems took the approach of specializing the interface to the device,
but it had a significant downside: every time a new type of hardware device is
invented, the system call interface has to be upgraded to handle that device.
One of the primary innovations in UNIX was to regularize all device input
and output behind a single common interface. In fact, UNIX took this one
giant step further: it uses this same interface for reading and writing files and
for interprocess communication. This approach was so successful that it is
almost universally followed in systems today. We will sketch the interface in
this section, and then in the next section, show how it can be used to build a
shell.
The basic ideas in the UNIX I/O interface are:
Uniformity. All device I/O, file operations, and interprocess communi-
cation use the same set of system calls: open, close, read and write.
Open before use. Before an application does I/O, it must first call open
on the device, file, or communication channel. This gives the operating
system a chance to check access permissions and to set up any internal
bookkeeping. Some devices, such as a printer, only allow one application
access at a time | the open call can return an error if the device is in use.
Open returns a handle to be used in later calls to read, write and close to
identify the file, device or channel; this handle is somewhat misleadingly
called a \le descriptor", even when it refers to a device or channel so there
is no file involved. For convenience, the UNIX shell starts applications with
open file descriptors for reading and writing to the terminal.
Byte-oriented. All devices, even those that transfer fixed-size blocks of
data, are accessed with byte arrays. Similarly, file and communication
channel access is in terms of bytes, even though we store data structures
in files and send data structures across channels.
Kernel-buffered reads. Stream data, such as from the network or key-
board, is stored in a kernel buffer and returned to the application on
request. This allows the UNIX system call read interface to be the same
for devices with streaming reads as those with block reads, such as disks
and Flash memory. In both cases, if no data is available to be returned
immediately, the read call blocks until it arrives, potentially giving up the
processor to some other task with work to do.
Kernel-buffered writes. Likewise, outgoing data is stored in a kernel
buffer for transmission when the device becomes available. In the nor-
mal case, the system call write copies the data into the kernel buffer and