Path: utzoo!attcan!uunet!seismo!ukma!tut.cis.ohio-state.edu!rutgers!jarvis.csri.toronto.edu!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!dmr From: dmr@alice.UUCP Newsgroups: comp.arch Subject: Re: the Multics from the black lagoon :-) Message-ID: <10468@alice.UUCP> Date: 12 Feb 90 08:17:36 GMT Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 119 These Multics interchanges are enchanting; such a delightful combination of thinly-veiled envy, nostalgia, and the occasional gloriously stupid claim. About three years ago there was another such discussion, and I wrote a short essay on what people were saying then. I can't remember if I ever posted it; probably not, since it sort of trails off without ending in much of a conclusion. Perhaps it's time to trot it out now and get some (more?) use out of it. Dennis Ritchie dmr@research.att.com att!research!dmr Subject: who needs Multics? [written early 1987] I've been following the Multics discussions with considerable interest. I was involved in Multics at an early stage and retain strong, though by now sightly fuzzy impressions of it. Obviously, they have been influenced by subsequent heavy involvement in Unix. One might characterize Multics as a system that tried to do everything, that had a grand conception of a new order for the world, and then had to contract considerably as various realities intruded. Ultimately, it seems, it has had to contract into nothing, although during its lifetime, it did achieve a great many of its design goals. And it has been quite influential. Unix, by contrast, started with a modest but exceedingly well-conceived design that has, so far at least, been able to accommodate enormous expansion in various directions, only some of which aim towards the most characteristic features of Multics. We have always been assiduous in acknowledging a strong debt to Multics and its immediate predecessor (CTSS); still, many components of this connection are by now so thoroughly assimilated into the culture that it is hard even to see them. Hugh LaMaster mentions TSS, IBM's answer to Multics. TSS did emulate some aspects of Multics; in particular it approximated the single-level store discussed below, but in other, crucial aspects it utterly missed the point. For example, TSS poisoned the user (and program) interface with JCLish, IBMish DD cards describing all sorts of wretched, irrelevant facts about files, instead of doing the job properly. The most characteristic feature of Multics, the design aspect that strikes one most strongly, is indeed the single-level store: the notion that files (in a directory hierarchy) are identified with segments (parts of the address space). Other systems have done this since and perhaps even before, but Multics is the system that tried most publicly and boldly. I think the effort was admirable, was worth trying, and may still hold life, but seems now to be flawed. Even though the underlying mechanisms were unified, there are really two separate aspects to the single-level store: program and data. The program aspect is the dynamic linking facilities that have been discussed (and envied) in this forum. Briefly, it means that use of a name in call-position `func()' causes the system to search, at runtime, in specifiable places, for a file containing the appropriate entry point, to attach the file to the address space, and to complete the linkage to the function. This is slow the first time, rapid thereafter. All in all, this was made to work well, and the effect is more elegant, transparent, and general than the `shared libraries' that one finds in many systems. It was however never fast enough in practice to be the universal mechanism for linking; very early in the game, the `binder' had to be introduced that bundled together libraries and commands in advance, to avoid the overhead of doing it every time the command was executed. At least in the early days, another, and important, Multics compromise had especially evil consequences. The original design called for each command to be executed in a new process, as is done in Unix. This was much too slow, largely owing to dynamic linking. (I remember the time to start a new process going from perhaps 20 CPU minutes, to a few seconds at the time we left the project.) Therefore, in Multics all one's commands execute in the same process, and use the same address space. This was fine so long as you were not changing any of the programs you were running. Say you recompiled the sine routine and ran your test program again. At best, the program would continue to use the old sine because that version was already linked into your address space (this was merely confusing); at worst, the test program would jump into the wrong place in the new sine routine (the segment contents were replaced but the old offset remained in the linkage table). This effect was known as "the KST problem" (KST= Known Segment Table) and the result was called "being KSTed." I am certain that it was papered over in later versions of the system, and modern Multics users may not even be aware of the problem, but it was a real pain for us. (Our general fix was to type hcs_$newproc and go get a cup of coffee.) In spite of the problems (they were eventually alleviated) the dynamic linking of programs probably can be counted a success. I don't thing the same is true of data. It is generally a pleasant, and almost universally applicable abstraction to imagine other programs appearing, and thereafter statically living in your own program's address space. The same abstraction simply fails in the case of data. Other people have pointed out the problems already; I'll reiterate: 1) Much data comes from devices that cannot convincingly be mapped (terminals, tapes, raw disks, pipes) 2) In the state of technology, even plain files cannot be mapped properly, because they are too big (I might need some correction on the second point, but I don't see how the Multics machine could deal transparently with segments larger than 256KW.) What actually happened was that, for the most part, people avoided the "single-level store" for data and used sequential IO via read and write calls. The Multics IO system was quite snazzy, and one of the first things we did with it was to write the "fsim"-- the file system interface module, that initiated your segment and put/got bytes in it, and did all the grotty but necessary things like set_bit_count. In other words, as a "feature," occasional use of data file mapping was convenient, but as an organizing principle, as a way of life, it was a bust; it was something that had to be programmed around.