Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uakari.primate.wisc.edu!indri!uflorida!gatech!udel!rochester!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs!rutgers!sun-barr!ames!hc!lll-winken!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <1023@aber-cs.UUCP>
Date: 22 Jul 89 14:39:23 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth (Disclaimer: my statements are purely personal)
Lines: 40

In article <13750@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes:
    
    I still like the FSS.  It would, of course, be nice if the FSS entries
    could be implemented as separate processes, and have the FSS be dynamically
    modifiable; then you could "advertize" (i.e. put into the FSS) a new
    "filesystem" type, whether it be a real filesystem, /proc, or whatever, and
    access it as part of the directory tree.
    
    Isn't Mach supposed to be able to do this to some extent?

Much better than this actually. Briefly, all access to data is thru ports;
you are not allowed to know what is on the other side of the port, and
ports can be transmitted across a port. You can ask the os port for a port
to the filesystem, and the filesystem port for a port to the file. You
can have multiple filesystems running on your machine, and you can even them
use concurrently from the same program. Directories can be ports that look
exactly like filesystem ports, which makes a lot of funny things possible.

This is not a precise description, but gives a gist of the power of having
unrestricted transmissible opaque capabilities. There are several papers
on Mach that describe the idea and its implications.

Historical notes: BSD has *two* similar facilities; one is the unimplemented
used defined domain capability, and the other is the idea tha in the UNIX
domain it is possible (well, it was buggy) to transmit file descriptors.
Using just this, it is possible to have several filesystem processes, a name
service process, with a well known Unix domain socket name. You ask the name
server for a socket/fd to one of the file servers, and then you can send on
this socket an open request for a file, and the filesystem process will
return a socket/fd for the open file, etc... Same for having multiple
TCP/IP, XNS, etc... servers outside the kernel. Like Mach, but without the
careful tuning to make this efficient.

Streams can also pass file descriptors in messages, and thus gain the same
flexibility. You can effectively push user processes on a stream, (above the
stream head, not below it, though) by this technique.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk