[TUHS] VFS prior to 1984

[Greg A. Woods]

At Wed, 24 Jun 2020 17:45:38 -0700, Adam Thornton <athornton at gmail.com> wrote:
Subject: Re: [TUHS] VFS prior to 1984
>
> On Wed, Jun 24, 2020 at 2:34 PM Greg A. Woods <woods at robohack.ca> 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 <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200625/f3a75344/attachment.sig>