/dev/fd info wanted

[Chris Torek]

In article <1171 at hcr.UUCP> john at hcr.UUCP (John R. MacMillan) writes:
>I'm looking for info on the /dev/fd devices on some Unixes.  I grasp
>the idea, but I'd like some specifics.  Do they behave liked a dup()ed
>fd, for instance?

The result of the call

	open(name, appropriate_mode)

where `name' points to a name like "/dev/fd/3" and appropriate_mode is
a mode that does not clash with the underlying access mode of the file
descriptor (here, 3) is identical to the result of

	dup(file_descriptor)

(here dup(3)).  Essentially, the `device' driver takes the minor number
from the open() call (minor(dev) in fdopen(dev_t dev, int mode)) and
calls the internal dup() routine after making a few security and sanity
checks.  (The file descriptor created by open() happens to be in
u.u_r.r_val1 at that point in the driver, which lets fdopen() know
which file descriptor to replace.)

In particular, opening /dev/fd/N with O_RDONLY or O_WRONLY can (if
fd N happens already to have that permission) wind up with a file
descriptor open for O_RDWR.

This is how it works in `4.4BSD' (or whatever it is called), at least,
and the code there is based on our code (Fred Blonder's and mine) as
modified to match the V8/V9 semantics, as far as I knew them.  (The
`modification' was to delete some of Fred's code, which did a second
open() iff the descriptor referred to a real file.  This applied the
mode argument to the underlying inode, rather than the present descriptor
permissions, and gave a separate seek pointer.  Sometimes this is
what you really want, but to have the semantics differ on files and
sockets seemed wrong.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris