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