Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Apr 2000 21:23:05 +0000 (GMT)
From:      Terry Lambert <>
Cc: (Terry Lambert), (Dag-Erling Smorgrav), (Poul-Henning Kamp),
Subject:   Re: Proposal: Union mount of fdesc on top of /dev
Message-ID:  <>
In-Reply-To: <> from "Chris Costello" at Apr 04, 2000 07:32:57 PM

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
> On Tuesday, April 04, 2000, Terry Lambert wrote:
> > I expect /dev/std* to eventually be recognized as "not useful" and
> > find its butt deprecated in favor of "/dev/fd{0-2}".
>    At this point, I believe that stdxxx may just be left alone
> as well as tty.  Currently fdesc mounts normally on a /dev/fd
> directory.
>    However, I don't think they will last forever, but will
> probably be supported up to a certain date before which
> "everybody has to MAKEDEV".  I also do not think /dev/stdxxx will
> be considered "not useful",

The intent of /dev/tty was to allow you to reopen your controlling
tty, after losing all file descriptors for it.

I really don't know what /dev/std* is for; it's not for your
controlling tty (that's what 'tty' is for).  It's not for doing
a descriptor pass to another program via UNIX domain sockets,
when you don't know the file name of an open descriptor (putatively
because you are a bad programmer, and failed to save the name you
used in the "open" call -- that's what /dev/fd/* is for).  It's
not so you can get another fd open on stdin/stdout/stdio (that's
what "dup" is for).

> but they, as separate device nodes,
> are certainly "bloat" considering that fdesc can be used for this
> and is much simpler, so why not keep the /dev files and lose the
> kernel /dev/std* code (and put in the fdesc code).

That's a good idea, if the intent of these nodes, seperate from
the fd nodes, was to maintain markers.  From my reading of "ls -l",
there isn't seperate code for this, though.  They use the same
major and minor as /dev/fd/{0-2}.  I guess we can consider this a
case of "putting the ``backwards'' into ``backwards compatability''".

>    This also allows us to yank out the /dev/fd/ static node
> support and replace them with more useful synthetic FS nodes.

This is a good idea, period.  There shouldn't be something visible
in the namespace that doesn't refer to something that's real (one
of the original intents of a devfs was to address this fact; the
other intents were avoiding synchronization, static node creation,
supporting NFS boots from systems that couldn't represent enough
bits in their major/minor numbers, supporting dynamically loaded
devices, and supporting "clone" devices (e.g. a _real_ /dev/pty/),

One drawback, though, is that the ideal place to do something like
this is by adding a "handler" for a portion of the devfs namespace
(like the /dev/pty/ handler would want to be), rather than using a
mount to do the job.  But a mount will work for now, I guess.

					Terry Lambert
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to
with "unsubscribe freebsd-arch" in the body of the message

Want to link to this message? Use this URL: <>