pts - STREAMS pseudo-tty slave driver
The pseudo-tty subsystem simulates a terminal connection, where the master side represents the terminal and the slave represents the user process's special device end point. The master device is set up as a cloned device where its major device number is the major for the clone device and its minor device number is the major for the ptm driver. There are no nodes in the filesystem for master devices. The master pseudo driver is opened using the open system call with /dev/ptmx as the device parameter. For more information, see the open(2) man page. The clone open finds the next available minor device for the ptm major device. A master device is available only if it and its corresponding slave device are not already open. When the master device is opened, the corresponding slave device is automatically locked out. No user may open that slave device until its permissions are adjusted and the device unlocked by calling the functions grantpt() and unlockpt(). For more information, see the grantpt(3C) and unlockpt(3C) man pages. The user can then invoke the open system call with the name that is returned by the ptsname() function. For more information, see the ptsname(3C) man page. See the example below.
Only one open is allowed on a master device. Multiple opens are allowed on the slave device. After both the master and slave have been opened, the user has two file descriptors which are the end points of a full duplex connection composed of two streams which are automatically connected at the master and slave drivers. The user may then push modules onto either side of the stream pair. The autopush(8) system will push the required STREAMS modules for terminal semantics on first open.
The master and slave drivers pass all messages to their adjacent queues. Only the M_FLUSH needs some processing. Because the read queue of one side is connected to the write queue of the other, the FLUSHR flag is changed to the FLUSHW flag and vice versa. When the master device is closed an M_HANGUP message is sent to the slave device which will render the device unusable. The process on the slave side gets the errno EIO when attempting to write on that stream but it will be able to read any data remaining on the stream head read queue. When all the data has been read, read returns 0 indicating that the stream can no longer be used. On the last close of the slave device, a 0-length message is sent to the master device. When the application on the master side issues a read() or getmsg() and 0 is returned, the user of the master device decides whether to issue a close() that dismantles the pseudo-terminal subsystem. If the master device is not closed, the pseudo-tty subsystem will be available to another user to open the slave device. Since 0-length messages are used to indicate that the process on the slave side has closed and should be interpreted that way by the process on the master side, applications on the slave side should not write 0-length messages. If that occurs, the write returns 0, and the 0-length message is discarded by the ptem module.
The standard STREAMS system calls can access the pseudo-tty devices. The slave devices support the O_NDELAY and O_NONBLOCK flags.
int fdm fds; char *slavename; extern char *ptsname(); fdm = open("/dev/ptmx", O_RDWR); /* open master */ grantpt(fdm); /* change permission of slave */ unlockpt(fdm); /* unlock slave */ slavename = ptsname(fdm); /* get name of slave */ fds = open(slavename, O_RDWR); /* open slave */
master clone device
slave devices (N = 1 -> number of ptys available)
Prior to Oracle Solaris 11.4, the user needed to push the ptem and ldterm modules onto the slave side of the pseudo-terminal subsystem to get terminal semantics, and the ttcompat module on the slave side for BSD compatibility ioctl calls, but only if open() was called from a program not linked for XPG4 or later standards. If called from a program linked with values-xpg4.o or values-xpg6.o, then open() would automatically push ptem, ldterm, and ttcompat modules onto the slave side, and callers pushing them as well would encounter unexpected behavior.
Oracle Solaris 11.4 added these modules to /etc/iu.system.ap so that they are automatically pushed by autopush(8) regardless of how the program is linked, and ensured that only one copy of each is pushed onto each stream.
Oracle Solaris 11.4 also added the openpty(3C) to encapsulate most of this detail behind a portable interface.