Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.arch Subject: Re: the Multics from the black lagoon :-) Message-ID: <33831@news.Think.COM> Date: 9 Feb 90 06:17:03 GMT References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 48 In article 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