On Thu, 10 May 2001, Todd Vierling wrote:

# On Thu, 10 May 2001, Greywolf wrote:
#
# : # >I know, it's all opinion, but the /dev/pts/NNN or
# : # > /dev/pty/NNN notation just really makes me cringe.  There must be a way
# : # > to hit a happy medium in there somewhere.
#
# : # You can't really like having a bazillion tty and pty devices all
# : # cluttered into one directory with all your other devices, can you?  What
# : # a horrible mess it creates!  It's like putting everything in "C:\" with
# : # no sub-directories!  "Yuck!" is my opinion of the current situation.
# :
# : When doing a "ls", yeah, it's unwieldy.  But when referencing them (which
# : is far more common), it's less painful to do so.
#
# No one cares very much about "ls"-ing a /dev/pts directory.  In fact, it
# probably would be very well suited to a dynamic fs, a la FDESC or the like;
# it's also amazingly simple to implement.

I don't think you could have come any closer to providing a reply which
is about 90 degrees out of phase with what I was saying.

First, if you want to talk prior art, BSD was there first.  Remember,
Berkeley came up with the concept of the pty.  SysV didn't incorporate
them until they incorporated networking (also originally by BSD).

Secondly, also 90 degrees out of phase (but you got there first):
Typically, no, you don't ls a /dev/pts directory -- but you *might* ls an
element or several therein (to determine ownership &c. It has its uses; it
doesn't take all that vivid an imagination to see what those might be).

Thirdly, since we don't care about "ls"ing the directory, le

# SVR4's /dev/pts/* mechanism has a LOT of prior art.  We should adopt it,
# since inventing a new scheme here is near zero gain for lots of effort
# [porting applications to use the brand-new scheme].

What "inventing"?  What "porting"?  openpty() is already there -- change it
once.  Applications should almost certainly not be calling their own brand
of openpty().

Of course, from what I can tell, our openpty() does not properly revoke()
the pty once it's decided to take it over, and the fact that openpty() lives
in userland instead of in the kernel a la MVR4's grantpt() probably doesn't
help matters.

I think the principle of implementing grantpt() and cloning properly for
pseudo-ttys is a good thing, by the way -- I'm not arguing against it...

				--*greywolf;
--
*BSD: Groovy Baby!