fd info wanted

john@hcr.UUCP (John R. MacMillan) (06/27/89)

I'm looking for info on the /dev/fd deviceson some Unixes.  I grasp
the idea, but I'd like some specifics.  Do they behave liked a dup()ed
fd, for instance?

I'd appreciate any help or references anyone could give me.  Thanks!
-- 
John R. MacMillan        No parking by the sewer sign a hot dog with a
HCR Corporation          razor broke there's water dripping up the spout
{utzoo,utcsri}!hcr!john  but I don't care let it all hang out -- The Nails

chris@mimsy.UUCP (Chris Torek) (06/28/89)

In article <1171@hcr.UUCP> john@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@mimsy.umd.edu	Path:	uunet!mimsy!chris