1

I know that the file /dev/ptmx is used to generate a master file for a pseudo-terminal. But I have found out that Fedora has another ptmx file (/dev/pts/ptmx):

enter image description here

What is the purpose of this second file?

  • 1
    Assuming you understand the purpose of /dev/ptmx, try mount | grep pts. – Satō Katsura May 19 '17 at 18:07
  • @SatoKatsura /dev/pts is a separate filesystem, so what? I suspect that the answer does have to do with that, but in what way? (I think the answer is if you have multiple instances of /dev/pts`, for a machine with virtual environments that shouldn't see each others' terminals.) – Gilles May 19 '17 at 22:40
  • 1
    @Gilles It's in RAM. Different views can be (and are) given to different processes. Pseudoterminals are requested at /dev/ptmx, which is the same for everybody, but they are allocated at /dev/pts, which is a "customized" view in RAM. /dev/pts/ptmx is there for the consistency of internal requests. All this improves security and saves space on disk (since, perhaps surprisingly, devices take a non-trivial amount of space on disk). And of course it's Linux-specific. Disclaimer: this is my recollection of what's going on. While I've used Linux since 0.99.x, I've never been a huge fan of it. – Satō Katsura May 20 '17 at 4:11
4
+100

The reason, like with many things in the world of computing, is history and backwards compatibility.

Back in 2.4.* kernels, before udev (the current virtual filesystem solution for /dev) existed in Linux, there was two competing solutions, the "traditional Unix way" of having the devices in a real directory on a root filesystem, and devfs, the first virtual filesystem solution for /dev.

The problem was, the author of devfs had constructed a completely new naming scheme for various devices, and people felt fairly strongly about it: some wanted to migrate to the new scheme and abolish the old one, others didn't see the need for migration. Some distributions used the old static devices, others chose devfs.

At that point, there was a fixed number of pseudo-TTY devices created at installation time. (By the way, this is still possible, if the CONFIG_LEGACY_PTYS option is set while compiling your kernel.)

Then, Unix98-style dynamically-allocated PTY devices were introduced. Implementing them on a static /dev directory required a virtual filesystem for /dev/pts, and this became known as the devpts filesystem. Also, having this as a separate filesystem would probably have made it possible to apply it on top of the dynamic devfs too without duplication of code.

The dynamically-allocated PTY devices quickly became the favored choice, because having /dev cluttered with hundreds of statically-allocated PTY devices, most of which might well never be used in the system's lifetime, was clearly nonsensical.

Then came Linux 2.6 and udev with it. It quickly obsoleted both the static /dev and devfs solutions. For backwards compatibility reasons, devpts filesystem still existed, but now the same functionality could be moved back to the main /dev filesystem, since it was now entirely RAM-based.

Today, for example, Debian 9 still mounts devpts filesystem to /dev/pts for legacy compatibility, but assigns /dev/pts/ptmx zero permissions by default - this is a sign that the devpts filesystem is probably being deprecated and will be removed at some future point.

# ls -l /dev/ptmx /dev/pts/ptmx
crw-rw-rw- 1 root tty  5, 2 Nov 22 11:47 /dev/ptmx
c--------- 1 root root 5, 2 Nov 12 14:59 /dev/pts/ptmx

If some program still needs /dev/pts/ptmx, that can be allowed by adjusting the default permissions, but this lets people know which programs are still using the older deprecated device name.

0

When a process opens /dev/ptmx (using posix_openpt() ), it gets a file descriptor for a pseudoterminal master (PTM), and a pseudoterminal slave (PTS) device is created in the /dev/pts directory.

When the master is opened the slave is locked. You can obtain the name of the slave and set it's permissions etc. and then unlock the slave. This allows control of the slave before it is accessible.

The slave emulates a real text terminal device, the master provides the means by which a terminal emulator process controls the slave.

The slave is a virtual implementation of a physical terminal and the master is a virtual implementation of the human typing on that terminal; the computer treats characters sent to the slave the same as if a human had typed them on a real terminal (limited by the permission setup when the master was created).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.