* The Multics Input/Output System
* Authors: R.J. Feiertag and E.I. Organick
* Field: OS/File Systems
* Reference: 3rd SOSP, 1971

Goal: Abstract away the details of hardware I/O devices.  In those
cases where more flexibility is needed, a lower-level interface is
provided.

Other pieces of Multics handle 1) making segments known and
dynamically linking in files to a process's address space and 2)
scheduling, especially the sleep/wakeup mechanism which is used to
multiplex the processor while waiting for I/O to complete.

Device independence: The I/O interface programmers write to is
independent of any particular hardware device.  Instead of referring
to devices, the program refers to abstract "sources" and "sinks" that
are mapped to actual hardware devices when the program is initialized
to be run.  This is "late binding" -- adhering to an abstraction and
binding it to an implementation as late as possible (right before it
is used).  This idea is applicable in almost all areas where
abstraction is applied.

A stream is a bidirectional communication path.  Conceptually it
provides a process with a (source, sink) pair that it can use to
communicate with an I/O device.  Streams are implemented using Device
Interface Modules (DIMs) that present the interface of a source and
sink, translating these requests into low-level hardware commands.
The Attach Table keeps the mapping between streams and hardware
devices (recall this binding happens at run time, so the kernel needs
to keep track of it).

GIOC: Generalized I/O Controller.  This is a hardware device; the GIM
(GIOC Interface Manager) is a software layer that interacts with the
GIOC.  All DIMs communicate with hardware devices through the GIM.
The GIM handles hardware interrupts from the GIOC; it is like the
"bottom half" of the BSD kernel (I think).  This means it runs
asynchronous with the rest of the system.

Blocking: I/O devices are slow.  Processes waiting for an I/O device
are marked as sleeping; when the GIM gets a hardware interrupt for the
device a process is waiting for, it marks it as not sleeping, and the
process will be scheduled to run.

Pseudo-DIMs: These DIMs talk with a pseudo-device instead of a
hardware device.  Ex: File system segment is presented as a stream by
the File System Interface Module (FSIM).  Ex2: stream with another
stream as its pseudo-device, i.e. a "synonym" stream which just passes
on all requests to its target stream.  Synonyms are used to provide a
level of indirection.  Standard input/output streams are by default
synonyms for the Console.  Processes referring to standard
input/output can be used with other devices (or even file system
segments) simply by changing the target of the synonym input/output
streams.  Another type of pseudo-DIM is the broadcast stream that has
multiple targets; this can be used to make a program like "tee".

Discussion: 

1. What is the relationship between abstraction and levels of
indirection?

2. Could the Multics stream abstraction be used for IPC?

3. Anti-mapped files: file system segments are memory-mapped, the
stream abstraction on top provides a read/write interface.

4. How are Multics streams different from pipes, sockets, message
passing?