ptm(7)ptm(7)NAMEptm - STREAMS master pty (pseudo-terminal) driver
SYNOPSISDESCRIPTION
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 connection
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, with (STREAMS pty emulation module) and (STREAMS line
discipline module) pushed on top (not shown for simplicity), provides a
terminal interface as described in termio(7). Whereas devices that
provide the terminal interface described in termio(7) have a hardware
device 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 writ‐
ten 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 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 driver. The master driver is opened using the system
call with 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 master 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 master and slave devices when they are opened. The user may
then push the necessary modules on the master and slave streams (e.g.,
and on for terminal semantics, and on for Packet Mode feature).
The master and slave drivers pass all STREAMS messages to their adja‐
cent drivers. Only the 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 flag is changed to flag and vice
versa whenever a message travels across the master−slave link. When
the master device is closed, an message is sent to the corresponding
slave device which will render that slave device unusable. The process
on the slave side gets the errno when attempting a 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 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 message is
sent to the corresponding master device. When the application on the
master side issues a or system calls and a 0 is returned. The user of
the master device decides whether to close the master device 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 termi‐
nal. If or is set, a read on the master device returns -1 with errno
set to if no data is available, and a write returns −1 with errno set
to if there is internal flow control on the stream.
The master driver supports the following requests:
Determines whether the file descriptor is that of an open master
device.
On success, it returns the major and minor number (type
dev_t) of the master device which can be used to deter‐
mine the name of the corresponding slave device. On
failure, it returns −1 with errno set to on HP-UX can
return valid device number with negative value. For
example, with major number of the STREAMS pty master
being 0x9c, will return 0x9C000000 which is a negative
number. Therefore, it is imperative that applications
check for an explicit −1 instead of "< 0" (less than 0)
on the return value.
is used by functions and User applications normally do
not need to invoke this ioctl. The format of this ioctl
is:
Unlocks the master and the corresponding slave devices.
On success, it returns 0. On failure, it returns −1
with errno set to is used by function User applications
normally do not need to invoke this ioctl. The format
of this ioctl is:
This ioctl puts the STREAMS pty in and out of Remote Mode.
When Remote Mode is on, input data will be flow-con‐
trolled and passed through without any input processing
regardless of the terminal mode. When the pty master
driver receives this ioctl, it will send an message
downstream to via and The command in the message is set
to or depending whether to turn on or off the Remote
Mode. The format of this ioctl is:
where the argument is set to 1 to turn on Remote Mode
and 0 to turn it off. Remote Mode is normally used when
doing remote line editing in a window manager, or when‐
ever flow-controlled input is required. Each write to
the master device produces a record boundary for the
process reading the slave devices. In normal usage, a
write of data is like the data typed as a line on the
terminal; a write of 0 (zero) bytes is like typing an
(End-of-File) character.
This ioctl allows the master process to send a signal to the slave
process.
The format of this ioctl is:
where the argument is the signal number as defined in
the header file For example the master process can send
an signal to the slave process by doing:
AUTHOR
was developed by HP and OSF.
FILES
Streams pty master clone device
Streams pty slave devices (0 <=
N < where is a kernel tunable parameter which can be
changed via SAM.
SEE ALSOinsf(1M), getmsg(2), ioctl(2), open(2), read(2), write(2), grantpt(3C),
ptsname(3C), unlockpt(3C), clone(7), ldterm(7), pckt(7), ptem(7),
pts(7), streamio(7), termio(7).
ptm(7)
