(was slashes, now NFS devices)

[Chris Siebenmann]

ekrell at ulysses.att.com (Eduardo Krell) writes:
| If you can access remote files, why can't you access remote devices using
| the same mechanism? Under RFS, special files are interpreted by the server.

 For NFS, I can think of two reasons, one technological, one
'political':
- NFS has no way of signalling when a device is opened or closed, or who
  is doing the opening or closing. Many character special devices and
  some block special devices have special semantics attached to opens
  and closes. There's also the issue of ioctl support, complete with
  byte order problems.
- Sun didn't think it was necessary to support accessing remote devices
  in NFS, since it was seen as a replacement for Sun's ND, not as
  something that was supposed to be widely generic (cf. the first
  Usenix paper on NFS).

 One can construct remote filesystems where devices and symbolic links
are handled on the server; RFS does at least devices 'right', and the
V8/V9/V10 netb protocol does both right (except for ioctls between
machines of different byte-sex/kernel ioctls). I have even heard of a
way of doing diskless machines with either protocol; invent a new
filesystem, one that's entirely in memory; then as part of the diskless
client /etc/rc, create such a filesystem, mount it on /dev, and
populate it.

 But NFS works, more or less, and is the de-facto standard at this point
so we're stuck with it, botches and all. And the ease of crash recovery
is nice (unlike some people, my machines don't run rcp.lockd).

--
    ported program:	  a program which takes constant or increasing
			  effort to port to each new machine.
    portable program: a program which takes less effort to port to
		      each new machine.
cks at hawkwind.utcs.toronto.edu	           ...!{utgpu,utzoo,watmath}!utgpu!cks