The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: tytso <tytso@mit.edu>
To: The Unix Heritage Society mailing list <tuhs@tuhs.org>
Subject: Re: [TUHS] Interesting commentary on Unix from Multicians.
Date: Sat, 9 Apr 2022 08:10:21 -0400	[thread overview]
Message-ID: <YlF3rb2m+AUfCPfj@mit.edu> (raw)
In-Reply-To: <m1ncvkN-000iJNC@more.local>

On Fri, Apr 08, 2022 at 02:02:23PM -0700, Greg A. Woods wrote:
> Single Level Storage is an awesome concept and removes so many ugly
> hacks from algorithms that otherwise have to process data in files.
> Doing data processing with read and write and pipes is effectively
> working through a straw whereas SLS allows all (reasonably sized) data
> to be presented in entirely complete randomly accessible arrays just by
> attaching a "file" to a segment.  Mmap() is a very poor replacement that
> requires a great deal extra bookkeeping that's next to impossible to
> hide from; and also there's the problem of the consistency semantics
> being different between the I/O based filesystems and direct memory
> mapping of their files, which Mmap() reveals, and which SLS eliminates
> (by simply not having any I/O mechanism for files in the first place!).

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)".

So I/O consistency could be done much like writing to persistent
memory, except that there would be no need for "CLFLUSH" (Who needs
multi-level memory caches when the clock cycle is pathetically slow?)
and no need to worry about write endurance exhaustion with core
memory, either.

So how much of the consistency benefits are due to the hardware, and
how much is due to the OS?  We could just as easily claim that Multics
is superior to Unix because it's immune to Spectre and Meltdown
attacks --- except that Unix on a PDP-11 would be immune to cache
based attacks as well.  Of course, Unix on a PDP-11 is a lot slower
than NetBSD on an modern x86_64 machines....

> 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?

     	   	    	    	    	       - Ted

  parent reply	other threads:[~2022-04-09 12:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07 16:32 Dan Cross
2022-04-08  5:30 ` Lars Brinkhoff
2022-04-08 13:34   ` Clem Cole
2022-04-08 14:14     ` Dan Cross
2022-04-08 13:59   ` Dan Cross
2022-04-08 15:28     ` Larry McVoy
2022-04-08 15:35       ` Dan Cross
2022-04-08 19:36       ` Rich Morin
2022-04-08 21:02       ` Greg A. Woods
2022-04-08 23:34         ` Andrew Warkentin
2022-04-09 19:28           ` Greg A. Woods
2022-04-09  3:33         ` Adam Thornton
2022-04-09 12:10         ` tytso [this message]
2022-04-09 13:09           ` Dan Cross
2022-04-09 19:14           ` Greg A. Woods
2022-04-08 15:45     ` Jon Steinhart
2022-04-08 16:07 Noel Chiappa
2022-04-10 17:14 Noel Chiappa
2022-04-10 17:31 ` Larry McVoy
2022-04-10 20:41 ` John Cowan

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=YlF3rb2m+AUfCPfj@mit.edu \
    --to=tytso@mit.edu \
    --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).