Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!styx!ames!ucbcad!ucbvax!sdcsvax!darrell From: darrell@sdcsvax.UUCP Newsgroups: mod.os Subject: Re: Who needs files? Message-ID: <2897@sdcsvax.UCSD.EDU> Date: Mon, 23-Mar-87 02:32:47 EST Article-I.D.: sdcsvax.2897 Posted: Mon Mar 23 02:32:47 1987 Date-Received: Fri, 27-Mar-87 06:06:58 EST Sender: darrell@sdcsvax.UCSD.EDU Organization: Sun Microsystems, Mountain View Lines: 69 Approved: mod-os@sdcsvax.uucp >> There was no such thing as a "file" in Multics. Everything was a segment, >> mappable into virtual memory via a system call. > >Incorrect. While a process can directly invoke a supervisory routine to make >a segment known to a process, the normal method was via a hardware fault "Normal" in what sense? If you wanted to get at a segment by a name *specified at run time*, which many many commands would, you had to call the system. In fact, the dynamic linker code that responded to those faults would, I believe, find the name of the segment being referenced and call the hardcore supervisor routine to map in in, so ultimately to get a segment into a process' address space *somebody* has to call the system to do it. > The process of making a segment (procedure or data) known takes a rather > lengthly discussion to describe all of the mechanics involved (omitted here). > It is not done by a "system call" but a hardware trap. Not really that lengthy. An instruction that made an external reference would do so through a pointer in the process' "combined linkage section". The pointer in question was initially a Fault Tag 2 pointer. That would cause a trap to the linker. The linker would use that pointer to find the name of the segment in which the location being referenced existed, and use the standard hardcore supervisor call to get a pointer to that segment. (This routine was called "hcs_$initiate_refname", or something like that, if I remember correctly. The name that was used for the segment was called a "reference name". To translate such a name to a segment, the supervisor searched your search path, which was a list of directories, for a file with the given name as a file name. Actually, an entry in the search path could refer to the Known Segment Table, which was a table that recorded all the segments that had already been "initiated" by "hcs_$initiate_refname".) If the reference were not to some offset from the base of the segment as a whole, but to an offset from a particular entry point in that segment (i.e., the segment is an object module), the linker would look for the entry point in the segment's symbol table and modify the pointer to point to that entry. In either case, it would then replace the FT2 pointer with the new pointer. (I forget whether it snapped any other links to that segment or entry point or not.) >Basically, a reference to a segment (by symbolic name) that does not >have a valid segment number assigned [(i.e.) its ITS (Indirect To Segment) >word "snapped" in the process combined linkage segment for this ring], If you're talking about an unsnapped link, when I was using Multics at school, they weren't ITS pointers at all, they were FT2 pointers. (Organick's book also describes it this way.) The trap didn't occur because the segment number was invalid, but because the pointer was one that always caused traps when a reference was made through it. Did they stop using FT2 pointers in a later version of Multics? >Also, conventional I/O was possible via DIMs (Device Interface Modules), >that is another topic definitely. If I remember correctly, you could (if you felt so inclined) call the low-level device driver routines directly. They didn't, however, have device-independent interfaces. The DIMs provided the device-independent interfaces; they generally didn't run in a privileged ring, but called the low-level I/O routines which did. There was also a DIM that referred to segments, so you could do the equivalent of "write" calls to files (which merely meant that the DIM copied data into the segment) or to devices. (Actually, the DIM supported "multi-segment files", which were files that could be larger than a segment. They were implemented as directories containing multiple segments that contained pieces of the data in the file.