🚀 go-pugleaf

In article <WRM1FGGxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>How did MULTICS handle objects that didn't look like large arrays:
     ^^^ please use the present tense.  While new releases are no longer
being developed, most of the Multics systems sold are still in use.

>terminals, tapes, and other things that fit well into the UNIX streams
>model?

Multics has an I/O library, which supports device-independent access to
stream and block mode sinks/sources (I don't say "devices", because the I/O
library also supports stream/sequential access to virtual devices).  In the
"attach" call the type of device being accessed is specified as a character
string, and the dynamic linker is used to convert this to a procedure
pointer; this procedure then fills in a structure with procedure pointers
for other operations on the device, and this collection of procedures is
known as an I/O module.  The actual access to particular devices is
implemented by ideosyncratic system calls, but the I/O module provides a
standard interface.  There's even an I/O module that makes segments and
multisegment files look like stream, sequential, or keyed files.

There are several advantages of this mechanism over the traditional style
of device access.  First of all, the kernel isn't cluttered with lots of
code that just converts device-specific operations into device-independent
operations; the only thing that really needs to be in the kernel is the
low-level device access and access control.  Second, not all virtual
devices need any kernel support, and they are implemented entirely in user
code; why should /dev/null access require a system call?  Third, since I/O
modules are user mode libraries it's easy for users to implement their own
virtual devices, and these were used similarly to Unix filters (I admit
that I/O modules are not as easy to write as Unix filters).  The Multics
equivalent to the Unix termcap and curses libraries is an I/O module that
implements type-independent access to video terminals; ioctls implement
window operations, while stream input invokes an Emacs-style input editor.

The major disadvantage is that most Multics programs are designed to access
memory-mapped files rather than use the generic I/O library, so it isn't as
easy to supply alternate input sources and output sinks to those programs.
But most programs don't need to access arbitrary devices, so it wasn't
perceived as a big problem (but this may be a case where you don't miss
what you haven't had).  A few years ago we added pipes to the Multics
shell; the syntax permits specifying I/O modules after the equivalent of <
and >, and also provides a way for input from an I/O module to be collected
into a temporary file and the pathname substituted into the command line.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar