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, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10808 invoked from network); 25 Jun 2020 19:41:28 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 25 Jun 2020 19:41:28 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DD1A69C283; Fri, 26 Jun 2020 05:41:25 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 9FBCF9C243; Fri, 26 Jun 2020 05:40:58 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id B52D79C243; Fri, 26 Jun 2020 05:40:56 +1000 (AEST) Received: from central.weird.com (unknown [198.96.117.51]) by minnie.tuhs.org (Postfix) with ESMTP id 9C7A19C226 for ; Fri, 26 Jun 2020 05:40:55 +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)S01060026bb6c284e.ok.shawcable.net[24.71.254.93] port=44931) by central.weird.com([198.96.117.51] port=587) via TCP with esmtp (6082 bytes) (sender: ) (ident using UNIX) id for ; Thu, 25 Jun 2020 15:40:51 -0400 (EDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #78 built 2020-Mar-25) Received: from (invalid client hostname: the DNS A record (with the targegt address [10.0.1.129]) for the hostname 'more.local' does not match the expected address [10.0.1.129])more.local ((no PTR matching greeting name)future.local[10.0.1.133] port=59182) by more.local([10.0.1.129] port=25) via TCP with esmtp (5572 bytes) (sender: ) id for ; Thu, 25 Jun 2020 12:40:47 -0700 (PDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2015-Feb-17) Message-Id: Date: Thu, 25 Jun 2020 12:40:50 -0700 From: "Greg A. Woods" To: The Unix Heritage Society mailing list In-Reply-To: References: <4FC7FA55-5035-41A2-B52F-AE26DC8BED2C@planet.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.3 (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_Thu_Jun_25_12:40:42_2020-1 Content-Type: text/plain; charset=US-ASCII At Wed, 24 Jun 2020 17:45:38 -0700, Adam Thornton wrote: Subject: Re: [TUHS] VFS prior to 1984 > > On Wed, Jun 24, 2020 at 2:34 PM Greg A. Woods wrote: > > > > As far as I can remember Multics didn't really have the concept of a > > "mount point". All storage was single-level, i.e. segments (equivalent > > in some respects to inodes, but they are also actually the value of the > > segment register in the virtual memory hardware), and so files were > > either physically in memory or paged out on physical disk devices or > > similar, or even out on tape. Where they actually resided was entirely > > and permanently hidden from the user. What was called the "filesystem" > > was a form of database representing a hierarchical namespace which > > pointed at all the known segments (files) regardless of where they were > > actually stored. > > > > > Coming to it from a Unix perspective, it's like all storage (core, disk, > tape) is mmap()ed. > > The segment-name database then is just an index relating symbolic names to > particular memory locations. Yes, exactly. A process is just a collection of segments of (virtual) memory, some containing code, some containing data, and more can be attached, some can be detached and/or swapped, as execution proceeds. E.g. for shared code, a module can be swapped out for another equivalent one, e.g. with a bug fix, without stopping or restarting the process (and perhaps, if it is a system library, without the user or application even knowing that has happened). > It all feels very upside-down to me, but that's probably because I grew up > in Unix and never actually used a Multics system until I emulated one with > dps8m. I kind of thought of it that way in my early years too, even though Multics was one of the first systems I learned, at the same time as I learned Unix. In Multics I/O takes a far lesser role than it does in Unix (or most any other OS then and since). Modeling everything as if it were I/O has some advantages in terms of implementation of the model (I guess it makes for far simpler operating systems), but personally I now think it's completely upside down and inside out from the user's perspective. Having to read all data before you can actually access it, and/or even just having to manage your allotted memory space and pointer offsets, is quite an annoying addition to any algorithm -- i.e. adding I/O in front of everything is like adding a significant problem on top of every other problem, every time, all the time. (Well using full-on only mmap() and a good language and compiler could probably hide much of the nastiness, but.... we don't really seem to do that even to this day, even in languages that could make it easy.) So, personally, I now see modeling everything as I/O as if it is forcing you to access all your data through the eye of a needle, every time, all the time. No matter how big the hole you still have to coil all your data up and push/pull it through if it is, or could be, bigger than the hole. I'm also quite sad that the extremely wide and near pervasive and long-term availability of a CPU family with half-decent support for segmented virtual memory has effectively been wasted for a generation or two or more of possibilities in OS design. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms --pgp-sign-Multipart_Thu_Jun_25_12:40:42_2020-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCXvT9vgAKCRBie18UwlnH hRvuAKDakrVTJPfY9pC4FCEtVE5WlCCBpACg7oCA5dWY/ApaEmS7P6fZlMGKcN8= =KRPT -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Jun_25_12:40:42_2020-1--