Symbolic links and RFS

[Benson Margulies]

In article <31533 at bu-cs.BU.EDU> bzs at bu-cs.BU.EDU (Barry Shein) writes:
>
>
>The easiest way to do this would be to have a file type which is
>actually a program which promises to produce a string for namei.

Seems to me that this newsgroup is re-inventing Multics (again).

One of the things that made Multics more flexible than Unix was that
the resolution of strings into I/O resources was done in user code
(usually in shared libraries). That is, to get the equivalent of a
file descriptor, one does/did (approximately):

	call iox_$open ("log_output", "log_io_ >udd>Foo>Margulies>log", 
		iocbp, code);

or

	call iox_$open ("log_output", "discard_", iocbp, code);

In the first example, log_output_ is a program that interposes itself
between the standard I/O interfaces (equivalent of the unix f*
interfaces) and a log file, providing log formatting. The second
example demonstrates that there was no need for a kernel /dev/null
driver.

The only code in the kernel was the actual code that spoke to the
hardware, and it usually wasn't device specific. For example, all tape
smarts were user code. The kernel support was a generic interface for
assigning a device and enforcing access control.

Now that shared libraries (albeit depressingly cumbersome ones) are
spreading through Unix, there is no reason that Unix couldn't grow
this sort of feature. As a refinement of barry's comment, consider a
file type like a symbolic link. The contents of this file would be
instructions, like the descriptions above, of how to dynamically link
to a program to actually do the I/O.


Benson I. Margulies