[TUHS] VFS prior to 1984

[Andrew Warkentin]

On 6/23/20, Bakul Shah <bakul at iitbombay.org> wrote:
>
> The fact is that the Unix byte/block read/write model goes only so far.
> Every device has its own peculiarities that need to be queried or
> controlled. And then there are controllers or USB device treees where
> you can hang useful devices at varius places. Bottom line: while dealing
> with real devices you can push this complexity around. You can't make it
> disappear. At one point a friend and I were looking at building a
> product using plan9 and one of the things I wanted to do was to make
> sure that the "ctl" file for every device responded to a "help" message
> that yielded one line per command and "help <command>" for more details.
> That way you can discover their capabilities at runtime.
>

Yes, complexity is unavoidable. IMO, the reason for going with a
purely file-oriented architecture isn't to make all user-visible APIs
use normal file calls, even though they are all going to be
implemented in terms of files (there's definitely a place for
libraries that provide a friendlier API on top of the file-based
transport). "Everything is a file" should not mean "all APIs are
visibly file-based".

The real advantages of a pure file-oriented architecture I can think
of off the top of my head are basically:

All security for all services in the system is enforced through a
single mechanism (rather than having many security primitives like
modern conventional OSes have)
On a microkernel, a purely stream-oriented IPC transport layer will
have better performance when dealing with bulk unstructured data than
a structured RPC transport layer with dynamic marshalling invoked on
every message (for servers that need RPC with dynamic marshalling, the
transport layer can easily support a type of file that preserves
message boundaries but otherwise has standard Unix semantics)
A purely stream-oriented IPC transport layer is simpler than one with
dynamic marshalling and has less attack surface
All services in the system can be extended, overridden, and exported
through the same mechanism (this includes making all parts of a purely
file-oriented OS network transparent for  basically free)
In some cases a higher-level service that extends another one doesn't
have to fully intercept all parts of the underlying interface (e.g. if
the underlying interface has multiple files and only some need to be
overridden, or possibly if some messages are treated as opaque)