Linux automatically populates a devtmpfs with the right devices and directory structure. This provides an almost complete tree for /dev, but the pts devices are notably missing.

For the pts devices, Linux provides another virtual filesystem named devpts. This however is also a collection of device nodes, sometimes causing surprises when a human installer simply mounts a devtmpfs to the chroot dev directory.

I find the design likely rooted from historical reasons, but even then, the kernel can simply populate /dev/pts automatically with devtmpfs, and any distros formerly using a udev-managed tmpfs with a devpts could migrate over to just devtmpfs. I can't think of a good reason for the decision otherwise.

1 Answer 1


The design is indeed historical: the devpts file system, tied to Unix98 PTY support, has been available for a very long time, whereas the devtmpfs file system isn’t quite as old.

devtmpfs could have included support for /dev/pts, but there are a few reasons to keep them separate. The two features are independent, so it is possible to configure a kernel with devpts and without devtmpfs, and vice versa. It is also possible to configure a system to use /dev/pts on top of any kind of /dev — static (part of the root file system), a separate udev-managed tmpfs (as you mention), or devtmpfs. Preserving all these possibilities requires a separate /dev/pts implementation anyway, so there probably isn’t much point in adding specific /dev/pts support to devtmpfs.

You must log in to answer this question.

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