From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28433 invoked from network); 9 Apr 2022 19:16:35 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 9 Apr 2022 19:16:35 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2F9C993D36; Sun, 10 Apr 2022 05:16:34 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 47A1D93D2A; Sun, 10 Apr 2022 05:14:55 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2DC4B93D2A; Sun, 10 Apr 2022 05:14:53 +1000 (AEST) Received: from central.weird.com (unknown [198.96.117.51]) by minnie.tuhs.org (Postfix) with ESMTP id CCB5093D1B for ; Sun, 10 Apr 2022 05:14:49 +1000 (AEST) Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for 'more.local': Unknown host)more.local ((no PTR matching greeting name)d207-6-82-137.bchsia.telus.net[207.6.82.137] port=50899) by central.weird.com([198.96.117.51] port=587) via TCP with esmtp (7516 bytes) (sender: ) (ident using UNIX) id for ; Sat, 9 Apr 2022 15:14:48 -0400 (EDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Feb-11) Received: from more.local ([10.0.1.129] port=50905) by more.local([10.0.1.129] port=25) via TCP with esmtp (7040 bytes) (sender: ) id for ; Sat, 9 Apr 2022 12:14:45 -0700 (PDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2022-Feb-11) Message-Id: Date: Sat, 09 Apr 2022 12:14:43 -0700 From: "Greg A. Woods" To: The Unix Heritage Society mailing list In-Reply-To: References: <7wh774dtvi.fsf@junk.nocrew.org> <20220408152834.GE29186@mcvoy.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/26.1 (x86_64--netbsd) MULE/6.0 (HANACHIRUSATO) X-Face: ; j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --pgp-sign-Multipart_Sat_Apr__9_12:14:17_2022-1 Content-Type: text/plain; charset=US-ASCII At Sat, 9 Apr 2022 08:10:21 -0400, tytso wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. > > To be fair, Multics had it a lot easier, because core memory meant > that every single memory access could be considered "durable storage", > so there was no real need for "fsync(2)" or "msync(2)". As Dan mentioned, actual "core" memory was long gone by the time Multics was in commercial use. Core memory was only used in the first-generation 6000 series (and presumably the GE-635 too), i.e. before 1975. One source says there was cache memory in the CPUs as early as 1974. The later machines, such as the DPS-8/70M ("M" for Multics) definitely came with 8KW cache memory that could be expanded up to 32KW. These systems were also generally used in multi-processing configurations, especially for Multics, with multiple CPUs, each with potentially multiple memory units (and multiple IOMm (I/O Multiplexer), later IMUs (Information Multiplexer Unit)). As for how this cache memory was used and how its consistency with main memory and with secondary storage was maintained, I don't know myself, but of course much documentation about Multics internals is available, along with all the source code, and it is running on simulators today. > > Multics dynamic linking makes any unix-ish implementation look most > > ugly, incredibly insecure, and horribly inefficient. Unix shared > > libraries are bad hack to simulate what Multics did natively and > > naturally, with elegance, and with direct hardware security support. > > What if we compared Multics dynamic linking to Solaris Doors? I don't think Doors is really relatable to Multics dynamic linking. As I understand it, Doors is more like RPC than directly shared code. In Multics all code, even kernel code, is generally shared -- in broad terms user processes just "gate" (i.e. jump) directly to code in a lower/inner "ring" to run system calls (e.g. Ring-0). Code doesn't even have to exist when first called (similar to how methods don't have to pre-exist in Smalltalk) -- the user gets a "linkage fault" and can write and compile the missing code and continue a program at the fault point. Also there's no such thing as "relocation" of code in Multics -- segmented memory means all segments have their own zero address and so all code is pure procedure and can be executed by many processes simultaneously simply by mapping the shared code segments into each process (as read-only, executable). Shared libraries of a sort (bound segments) do exist, partly because of performance issues (dynamic link faults are expensive in Multics, especially on hardware of the day), and partly because of addressing limitations (only a quite limited number of segments can be attached to any given process), and partly because otherwise there would be effectively one global namespace for all symbols exposed by each compilation unit in a user's $PATH. One of the difficult things for Unix people to wrap their heads around is the difference between a "process" in Unix and in Multics. One way to think about it that has helped me figure it out is this: In Multics you have a "shell" program which you interact with just like with "sh" in Unix, but it's not a separate process in Multics -- just a unit of code that effectively runs when no other program is running. So generally a user only runs one process at a time, even though it may transition through hundreds or thousands of programs during its existence. Multics did eventually have the concept of multi-threading and a form of co-operative multi-tasking too, though I don't know as much about these. I think the latter would/could effectively be like having multiple processes in one login session in Unix and it is said this facility was used to implement network service daemons for example. Now I don't believe the Multics concept of "process" is strictly necessary to support its concepts of Single Level Storage or even Dynamic Linking. I believe those could be used equally well in a system with more Unix-like processes, though some mix of concepts might be required to truly benefit from all the features of Multics-style dynamic linking. One way I've been thinking of Multics lately is that it's more like modern virtualization (e.g. Xen), but with added OS services such as a filesystem and controlled access to shared "inner ring" code; and indeed that's more or less how it was described in early Multics concept papers, assuming you transmogrify the old terminology of the day into modern lingo. Each user gets a computing environment that gives them the impression they have full use of the machine, and it comes along with pre-existing useful code and various useful services, including a filesystem the ability to communicate with other users and other machines. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms --pgp-sign-Multipart_Sat_Apr__9_12:14:17_2022-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCYlHbDQAKCRBie18UwlnH hUggAJ45ZeOXl33Se5M+DJzLrIpHaBNZXgCg+rtm3Kzplh4wQJP7f8BBJNtR2Qo= =UxTe -----END PGP SIGNATURE----- --pgp-sign-Multipart_Sat_Apr__9_12:14:17_2022-1--