Re: [TUHS] Interesting commentary on Unix from Multicians.

[Andrew Warkentin <andreww591@gmail.com>]

On 4/8/22, Greg A. Woods <woods@robohack.ca> 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!).
>
I think it's useful to have both I/O and memory views for files.
Things like commands that work equally well whether stdout is a disk
file or something like a pipe wouldn't work so well in a system where
disk files can only be accessed through a memory-like interface.
However, I guess the I/O interface could just be implemented with
library functions rather than real I/O syscalls for disk-like files.

Maybe I could try doing something like that in my OS but I'm not
completely sure if it would affect performance because it will be
QNX-like, and reads and writes would probably require the VFS to act
as an intermediary sometimes whereas that wouldn't be the case with
I/O since reads and writes would otherwise map onto kernel message
passing without any intermediary servers.