Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Apr 2000 21:23:05 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        chris@calldei.com
Cc:        tlambert@primenet.com (Terry Lambert), des@flood.ping.uio.no (Dag-Erling Smorgrav), phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-arch@freebsd.org
Subject:   Re: Proposal: Union mount of fdesc on top of /dev
Message-ID:  <200004052123.OAA05958@usr07.primenet.com>
In-Reply-To: <20000404193257.N27486@holly.calldei.com> 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/),
etc..


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
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?200004052123.OAA05958>