5

On my Archlinux, /dev/pts is mounted by the devpts, so who created the /dev/pts/ptmx device node? What's the purpose of this node? it's the same (Major=5 Minor=2) device node same as /dev/ptmx/, but with different access mode, for what?

Improve this question
1
  • 2
    "who created /dev/pts/ptmx?" devpts, of course. # mkdir /tmp/pts; mount -t devpts pts /tmp/pts; ls -l /tmp/pts.
    – user313992
    Jan 6, 2019 at 15:20

1 Answer 1

Reset to default
18

The old AT&T System 5 mechanism for pseudo-terminal slave devices was that they were ordinary persistent character device nodes under /dev. There was a multiplexor master device at /dev/ptmx. The old 4.3BSD mechanism for pseudo-terminal devices had parallel pairs of ordinary persistent master and slave device nodes under /dev. These were special device nodes on an ordinary disc filesystem.

On OpenBSD, some of this is still true nowadays. /dev is still a disc volume, and slave devices are still real on-disc nodes. They are created on demand, however. The kernel internally issues the relevant calls to create new device nodes there when issued a PTMGET I/O control on the /dev/ptm device.

On FreeBSD, none of this is still true. There isn't even a multiplexor device any more. /dev is not a disc volume at all. It is a devfs filesystem. Slave devices appear in the devfs filesystem under its pts/ directory in response to the posix_openpt() system call, which is an outright system call, not a wrapped ioctl() on an open file descriptor to some "multiplexor" evice.

For a while on Linux, pseudo-terminal slave devices were persistent device nodes. What you are looking at is its "new" devpts filesystem (where "new" means introduced quite a few years ago, now) in conjunction with devtmpfs. This almost permits the same way of doing things as on FreeBSD with devfs.

But there are some differences. In particular, there is still a "multiplexor" device.

  • In the older "new" devpts system, this was a ptmx device in a different devtmpfs filesystem, with the devpts filesystem containing only the automatically created/destroyed slave device files. Conventionally the setup was /dev/ptmx and an accompanying devpts mount at /dev/pts.
  • But Linux people wanted to have multiple wholly independent instances of the devpts filesystem, for containers and the like, and it turned out to be quite hard synchronizing the (correct) two filesystems when there were many devtmpfs and devpts filesystems. So in the newer "new" devpts system all of the devices, multiplexor and slave, are in the one filesystem.

    For backwards compatibility, the default was for the new ptmx node to be inaccessible unless one set a new ptmxmode mount option. In backwards compatibility mode one could still run things the older single-instance way, and one did by default unless one used an explicit newinstance option when mounting a devpts.

  • In the even newer still "new" devpts (that has been around since 2016) the per-instance multiplexor device in the devpts filesystem is now the primary multiplexor, and the ptmx in the devtmpfs is a shim provided by the kernel that tries to mimic a symbolic link, a bind mount, or a plain old actual symbolic link to pts/ptmx. The multiple-instance way is now the only way.

Further reading

Improve this answer
0

Not the answer you're looking for? Browse other questions tagged .