The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Greg A. Woods" <woods@robohack.ca>
To: The Unix Heritage Society mailing list <tuhs@tuhs.org>
Subject: Re: [TUHS] VFS prior to 1984
Date: Thu, 25 Jun 2020 12:40:50 -0700	[thread overview]
Message-ID: <m1joXjr-0036ttC@more.local> (raw)
In-Reply-To: <CAP2nic0LSw4zv7bQ1dZvi7Js1V0t-E9BJ-3xHHHBwr-SOp-DCg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3495 bytes --]

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

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2020-06-25 19:41 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23  9:09 Paul Ruizendaal
2020-06-23 14:01 ` Larry McVoy
2020-06-23 15:12   ` Clem Cole
2020-06-23 15:55     ` Rich Morin
2020-06-23 20:38     ` Rob Pike
2020-06-23 20:57       ` Larry McVoy
2020-06-24  5:14       ` arnold
2020-06-24 21:08         ` Dave Horsfall
2020-06-24 19:30       ` Clem Cole
2020-06-24 19:36     ` Larry McVoy
2020-06-25  6:52       ` Rob Gingell
2020-07-05  0:05       ` Dave Horsfall
2020-07-05  0:16         ` Larry McVoy
2020-07-06  4:42           ` Dave Horsfall
2020-07-06 16:51           ` Chris Torek
2020-07-06 23:23             ` [TUHS] ECC memory John Gilmore
2020-07-07  1:07             ` [TUHS] VFS prior to 1984 Bakul Shah
2020-07-05  1:43         ` Clem Cole
2020-07-05 14:43           ` Larry McVoy
2020-07-05 18:40             ` Arthur Krewat
2020-07-05 20:08             ` Clem Cole
2020-07-05 20:42               ` John Cowan
2020-07-05 21:04                 ` Clem Cole
2020-07-05 21:14                   ` Dan Cross
2020-06-24 16:51 ` Anthony Martin
2020-06-24 17:31   ` Anthony Martin
2020-06-24 18:31   ` Paul Ruizendaal
2020-06-25  0:56     ` Rob Gingell via TUHS
2020-06-25  4:15       ` [TUHS] Oh, things were very different Rich Morin
2020-06-25 15:45         ` Lawrence Stewart
2020-06-25 16:24           ` Warner Losh
2020-06-25 17:57           ` Arthur Krewat
2020-06-25 20:22         ` Dave Horsfall
2020-06-25 20:42           ` Michael Kjörling
2020-06-25 20:49           ` Clem Cole
2020-06-26  0:48             ` Dave Horsfall
2020-06-24 19:05   ` [TUHS] VFS prior to 1984 Paul Ruizendaal
2020-06-24 20:27 ` Derek Fawcus
2020-06-24 21:33 ` Greg A. Woods
2020-06-25  0:45   ` Adam Thornton
2020-06-25 19:40     ` Greg A. Woods [this message]
2020-06-23 22:17 Norman Wilson
2020-06-23 22:24 ` Dave Horsfall
2020-06-24  4:09   ` Warner Losh
2020-06-24  5:10     ` Dave Horsfall
2020-06-24  5:33       ` Bakul Shah
2020-06-24  9:10         ` Andrew Warkentin
2020-06-24 14:31 Noel Chiappa
2020-06-24 15:21 ` Clem Cole
2020-06-24 17:51 Noel Chiappa
2020-06-24 18:13 ` Richard Salz
2020-06-24 18:46   ` Lars Brinkhoff
2020-06-24 18:31 Norman Wilson
2020-06-25  6:22 ` arnold
2020-06-25 19:31 Noel Chiappa
2020-06-25 20:23 Noel Chiappa
2020-06-25 20:25 Noel Chiappa
2020-06-26  5:49 ` Lars Brinkhoff
2020-06-26  8:34   ` Dave Horsfall
2020-06-26 11:13     ` arnold
2020-06-29  9:11 Paul Ruizendaal
2020-06-29 14:45 ` Larry McVoy
2020-06-29 14:53   ` Paul Ruizendaal
2020-06-29 15:14     ` Larry McVoy
2020-06-29 16:34 ` Heinz Lycklama

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1joXjr-0036ttC@more.local \
    --to=woods@robohack.ca \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).