home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
unix
/
volume10
/
dev.fd
/
README-FIRST
< prev
Wrap
Text File
|
1987-08-06
|
2KB
|
39 lines
README-FIRST
The files in this directory contain the source code for the "fd"
pseudo-device driver for 4.[23] BSD Unix. The idea originated with the Eighth
Edition Research Unix system.
The original version for BSD Unix was done by Fred Blonder at the
University of Maryland. He simply had a bunch of devices, /dev/fd0 - /dev/fd19.
The Research Unix system uses a /dev/fd directory, with files 0 - 19.
The latter version of the mechanism is used by the Korn shell (ksh)
for "process substitution", a feature whereby programs can read/write files
which are really pipes from/to other processes. This mechanism allows one
to have pipelines that move data in more than one dimension. Once this
driver is installed, the ksh needs to be recompiled. Process substitution
is new in the version of the ksh known as "ksh-i". I don't know if the older
ksh had it as an undocumented feature.
To allow the ksh to use the fd driver, and for compatibility with
Research Unix, I have changed the fd.4 man page to refer to the /dev/fd
directory.
This version of the fd driver now includes code for NFS systems.
Unfortunately, for reasons detailed in the source code, the NFS version
requires a small patch to the stock system code. The file that is affected
is /sys/specfs/spec_vnodeops.c. This patch is included in the file PATCH.
This patch should not affect any other system code (famous last words!).
Besides the NFS version, I have added some additional error checking, and
a bug fix to the inode version as well. This is commented, so if someone
wants the exact original code, they can change it back.
The NFS version works without change on both Sun systems running
SunOS 3.3, and Mt. Xinu 4.3 + NFS 3.2. On the Sun, "make depend" will not
work because of where the inode.h file is included from if NFS is not
defined. This is not a very big deal, just comment out that line. The
interaction with the file locking mechanisms is not clear. (i.e. I didn't
bother to investigate it.)
Arnold Robbins
Emory University Computing Center
July, 1987