Re: glibc and Unix98 PTY's

[Mark Kettenis <kettenis@phys.uva.nl>]

   From: hpa@transmeta.com (H. Peter Anvin)
   Date: 	8 Aug 1998 23:20:27 GMT

   I just realized that glibc uses the TIOCGPTN ioctl() to determine the
   name of a PTY opened using /dev/ptmx.  Currently, this returns the
   minor number which isn't quite right for 2.1.115 and above which has
   pty's on multiple majors.  I would like to suggest the following
   change in semantics for TIOCGPTN, please holler if you object:

   TIOCGPTN will be undefined (returning -1 errno=ENOIOCTLCMD) on BSD
   ptys (BSD ptys can no longer be opened using /dev/ptmx due to a
   security hole that opens); TIOCGPTN will return the PTY number (which
   may be different from the minor number) for Unix98 PTYs,
   i.e. /dev/pts/316 (137,60) would return 316.

   I suspect this will make glibc do the right thing in all cases, but I
   wanted to double-check here first.  Please let me know yea/nay as soon
   as possible.

Yea, this sounds to me as the way it should have been implemented
right from the start.  A clear distinction between BSD-style and
SYSV-style pty's.  Some small changes in the glibc code will be
necessary but they will be simplifications rather than complications.

This raises the following question.  Should the orthogonality between
BSD-style and SYSV-style pty's be reflected in the function glibc
defines?  Thus

 * openpty()/forkpty() - operate on BSD-style pty's only.

 * getpt(), granpt(), unlockpt(), ptsname() - operate on SYSV-style
   pty's only.

For openpty and forkpty, I think this is a good idea since there may
be programs out there that assume that when they use openpty() they
get a pair named `/dev/pty??', `/dev/tty??' (or what is more
important, that the terminal is a file in the directory `/dev' and not
in a subdirectory.  Especially programs that do utmp accounting would
be unpleasently surprised.

For the other functions it is not really necessary.  If they can do
their job, let them do it.

What do we do with 2.1.7x < kernel < 2.1.115, where TIOCGPTN has the
old semantics?  I'd say that we do not support them, since we're
talking about development versions of both the kernel and glibc.  But
it might cause some inconveniences..

Mark

PS I'm not sure what the linux-gcc list is for anymore, but the glibc
hackers can be reached at libc-hacker@cygnus.com.