ptm.7 (2010 09)
p
ptm(7) ptm(7)
NAME
ptm - STREAMS master pty (pseudo-terminal) driver
SYNOPSIS
#include <sys/stropts.h>
#include <sys/ptyio.h>
#include <sys/strtio.h>
int open("/dev/ptmx", O_RDWR);
DESCRIPTION
A pseudo-terminal (pty) consists of a tightly-coupled pair of character devices, called the master device
and slave device. The pty master and slave device drivers work together to simulate a terminal connec-
tion where the master provides a connection to the pseudo terminal server process and the slave provides
a terminal device special file access for the terminal application processes, as depicted below:
----------------
| pty functions |
Application <--> |----------------| <--> Server
Processes | Slave | Master | Process
| (pts) | (ptm) |
----------------
The slave driver,
pts with ptem (STREAMS pty emulation module) and ldterm (STREAMS line discip-
line module) pushed on top (not shown for simplicity), provides a terminal interface as described in ter-
mio(7). Whereas devices that provide the terminal interface described in termio (7) have a hardware dev-
ice behind them; in contrast, the slave device has another process manipulating it through the master
side of the pty. Data written on the master device is given to the slave device as input and data written
on the slave device is presented as input on the master device.
In order to use the STREAMS pty subsystem, a node for the master pty driver
/dev/ptmx and N
number of slave pty devices must be installed (see pts (7) for details on slave pty). There are no nodes in
the file system for each individual master device. Rather, the master driver is set up as a STREAMS
clone driver (see clone (7)) with its major device number set to the major for the clone driver and its minor
device number set to the major for the
ptm driver. The master driver is opened using the
open() sys-
tem call with
/dev/ptmx as the device file parameter. The clone open finds the next available minor
number for the master device. The master device is available only if it and its corresponding slave device
are not already opened. Only one open is allowed on a master device whereas multiple open are allowed
on the slave device. When the master device is opened, the corresponding slave device is automatically
locked out (see pts (7) on how to unlock the slave and obtain the slave device name). After both the mas-
ter and slave have been opened, the user has two file descriptors which represent the end points of a full
duplex connection composed of two streams. These two streams are automatically connected by the mas-
ter and slave devices when they are opened. The user may then push the necessary modules on the mas-
ter and slave streams (e.g., ptem and ldterm, on pts for terminal semantics, and pckt on
ptm for
Packet Mode feature).
The master and slave drivers pass all STREAMS messages to their adjacent drivers. Only the
M_FLUSH
message needs some special processing because the read queue of the master is connected to the write
queue of the slave and vice versa. Hence, the FLUSHR flag is changed to FLUSHW flag and vice versa
whenever a M_FLUSH message travels across the master−slave link. When the master device is closed,
an M_HANGUP message is sent to the corresponding slave device which will render that slave device
unusable. The process on the slave side gets the errno [ENXIO] when attempting a write() system call
on the slave device but it will be able to read any data remaining on the slave stream. Finally, when all
the data have been read, the read() system call will return 0 (zero) indicating that the slave can no
longer be used. On the last close of the slave device, a zero-length M_DATA message is sent to the
corresponding master device. When the application on the master side issues a read() or getmsg()
system calls and a 0 is returned. The user of the master device decides whether to close the master dev-
ice file which will dismantle the streams on the master side. If the master device remains opened, the
corresponding slave device can be opened and used again by another user.
Unlike the slave device, the master device does not act like a terminal. If
O_NDELAY or O_NONBLOCK is
set, a read on the master device returns -1 with errno set to [EAGAIN] if no data is available, and a write
returns − 1 with errno set to [EAGAIN] if there is internal flow control on the stream.
The master
ptm driver supports the following ioctl() requests:
HP-UX 11i Version 3: September 2010 − 1 − Hewlett-Packard Company 1