<< libpt >> What the heck is it?

[Guy Harris]

>Under System V.3.2, what does the pt library (libpt.a) do?

Supports pseudo-terminals.

>It appears to include the functions
>
>		ptsname()
>		grantpt()
>		unlockpt()

Those are documented in the Third Edition of the System V Interface
Definition; that's the SVID for S5R4, in which the pseudo-tty support is
official.  No guarantees that this *exactly* matches the S5R3.2 version,
but it's probably close, at minimum.

>and appears to be associated with the device
>
>		/dev/ptmx

A "clone" device, which you use to get a pseudo-tty master.  You open
"/dev/ptmx" and either:

	it fails, e.g. because there aren't any pseudo-ttys left;

or

	it succeeds, and the resulting file descriptor refers to some
	not-already-in-use pseudo-tty master.

(I.e., if process A opens "/dev/ptmx", and then process B opens it, the
two file descriptors do *NOT* refer to the same device; they refer to
different pseudo-ttys.  This avoids the grot needed with BSD-flavored
pseudo-ttys, in which the program has to try opening all the pseudo-tty
masters....)

>and with files of the form
>
>		/dev/ptsNNN

Those are the pseudo-tty slaves; there's an "ioctl" you do on the master
side to find out which pseudo-tty master it is, and you use that to get
the name of the slave.  (Actually, "ptsname()" does it for you.)

>It is used throughout the X11R4 Streams code, but I can find no references
>for this stuff anywhere. Clues?

The X11R4 STREAMS code uses pseudo-ttys for local connections to the
server, since S5R3 doesn't have UNIX-domain sockets.  Arguably a hack,
but....

>I can deduce that mutual exclusion,

If you're thinking of "unlockpt()", it's less mutual exclusion than a
technique to keep other processes from opening a slave device that
hasn't yet been properly set up by the process handling the master.

>slave names,

Yup; "ptsname()", to quote the "ptsname(BA_LIB)" page in the SVID,
"returns the name of the slave pseudo-terminal driver associated with a
master pseudo-terminal device."