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