>>543648here are 6 different concepts in unix:
1. directories (1:many, local)
2. symlinks (1:1, non-local/cross filesystem)
3. hardlinks (1:1, semi-non-local/same filesystem)
4. filesystem mounts (1:many, non-local)
5. loopback filesystems (1:many, non-local)
6. pipelines (1:1, local)
how possible is it to consolidate this into one abstraction?
1&2: a directory points to a set of nodes that MUST be its children. meanwhile a symlink points to a single node that is not its child. these could be merged into a pointer that is 1:many, but non-local (not mandatory for the nodes to be its children)
3: a hardlink is simply another name for a file, which may be located somewhere else. a file in unix can have multiple filenames. I've never really heard of a compelling use for this over symlinks besides the fact that the implementation of symlinks is kind of broken. so let's dump this.
4: plan 9 did away with symlinks, and used filesystem mounts for everything. hurd has a translator mechanism which is used to implement both filesystem mounts and symlinks. in hurd, a symlink is a very simple translator that points from one single node to another single node. and you can create a symlink with the "settrans" command. so symlinks can be rolled into 4.
5: a loopback filesystem is a filesystem stored in a file on top of another filesystem. the architecture of OSes like hurd and plan9 is recursive, so there is no distinction between a "real" and "fake" filesystem, a filesystem server sees the underlying backend the same either way. so this is merged into 4.
6: in linux, a process has a set of i/o virtual files in /proc/self/fd/ which contain the data coming in and out. there is also a "pipefs" filesystem which is inaccessible from the root filesystem where the pipeline is set up, and is accessed through a separate "pipe" syscall instead of normal fs syscalls. I am unsure of the relation between pipefs and /proc, given one is accessible under / and the other isn't. It could be that pipes were implemented first with pipefs and /proc was added later for instrumentation purposes. Anyways, you could just create pipes by pointing between these /proc/ files, and do away with pipefs and pipe(). And have the shell deal with the boilerplate of setting up and tearing down the communication files. This also sets up the possibility for "seekable pipes", which would mean chaining together any number of programs that can output filesystem-like data
https://lkml.indiana.edu/hypermail/linux/kernel/0411.3/0739.htmlso what would a merger of all of this look like?
-a pointer is a special (simple) type of translator
-a pointer would point to an arbitrary number of other nodes at arbitrary locations
-the filesystem would be a graph instead of a tree as each node can share the same children
-a node can contain another such pointer, or it may contain a more complex translator that translates a protocol for filesystem access
-every pointer IS a filesystem mount, usually a very simple one (see 4)
-the contents of every filesystem are "flat" like an object store by default with no defined structure except that defined by the applications through the creation of filesystem pointers to create a tree (or graph)
-no directories/symlinks/hardlinks/loopbacks
-as all of the structure of the metadata is created by the structuring of simple pointer translators, all filesystems can be made way simpler to implement as they no longer have to understand what the structure of the filesystem is. they don't have to traverse directory trees or anything. they just have to write data and commit it.