打开伪终端的主控部分后
int fd_pseudo_term_master = open("/dev/ptmx",O_RDWR);
有/dev/pts/[NUMBER]创建的文件，代表slave他的伪终端的一部分。
像我这样无知的人可能会认为，在完成之后，ptsname(fd_pseudo_term_master,filename_pseudo_term_slave,buflen);应该将其设置为简单地
做好事int fd_pseudo_term_slave = open(filename_pseudo_term_slave,O_RDWR);。
然而，必须有一个非常重要的“锁定”伪终端从机用例，因为为了简单起见，在open调用之前，必须使用man 3 unlockpt来“解锁”。
我无法找出这个用例是什么？最初锁定伪终端需要什么？用代码实现了什么（取自 libc）
/* Unlock the slave pseudo terminal associated with the master pseudo
terminal specified by FD. */
int
unlockpt (int fd)
{
#ifdef TIOCSPTLCK
int save_errno = errno;
int unlock = 0;
if (ioctl (fd, TIOCSPTLCK, &unlock))
{
if (errno == EINVAL)
{
errno = save_errno;
return 0;
}
else
return -1;
}
#endif
/* If we have no TIOCSPTLCK ioctl, all slave pseudo terminals are
unlocked by default. */
return 0;
}
如果可能，答案将详细说明用例，历史或当前。
问题的额外部分是：
当前的 linux 内核是否仍然依赖于“锁定伪终端从站”的这种功能？
想法：这是避免比赛的低效尝试吗？
等待答案我已经更多地研究了 linux 内核源代码，但自己没有任何好的答案。但是，似乎可以从伪终端的初始锁定情况中“提取”的一种用途是为伪终端主进程提供一些时间来设置对文件的访问权限/dev/pts/[NUMBER]，以防止某些用户首先访问该文件。这可以作为答案的一部分吗？奇怪的是，然而，这种“初始锁定”状态似乎并不能真正阻止从属文件的多次打开，至少我认为在这里可以保证原子性。
用于伪终端从设备的旧 AT&T System 5 机制是它们是
/dev. 有一个多路复用器主设备/dev/ptmx。用于伪终端设备的旧4.3BSD 机制在/dev.在这两种情况下，这意味着从设备文件在最后一个文件描述符关闭后保留了它们最后的所有权和权限。
grantpt()因此，在（重新）分配（重新使用的）伪终端之后，修复从设备文件的所有权和权限的功能的演变。open()这反过来意味着，当程序在和之前拥有从设备的人之间设置一个重复使用的伪终端时，有一个窗口grantpt()可以潜入并打开它，可能会访问其他人的终端. 因此，伪终端从字符设备的想法开始于锁定状态，在该状态下它们无法打开，并在成功执行unlockpt()后被解锁。grantpt()多年来，事实证明这是不必要的。
如今，从设备文件不是持久的，因为内核自己制造和销毁东西
/dev。打开主设备的行为要么重置从设备权限和所有权，要么直接重新创建从设备文件（在后一种情况下，当所有打开的文件描述符关闭时，从设备文件再次消失），在任何一种情况下都是原子的相同的系统调用。PTMGET上 I/O 控件功能的一部分/dev/ptm。/dev仍然是一个磁盘卷，内核在内部发出相关调用以在那里创建新的设备节点并重置它们的所有权和权限。posix_openpt()系统调用完成的。/dev根本不是光盘卷。它是一个devfs文件系统。它不包含“多路复用器”设备或主设备文件，因为posix_openpt()是直接的系统调用，而不是包装ioctl()在打开的文件描述符上。从设备出现在devfs其pts/目录下的文件系统中。因此，内核确保他们从头开始拥有正确的权限和所有权，并且没有机会之窗让他们拥有陈旧的权限。因此，
grantpt()和unlockpt()库函数本质上是无操作的，其唯一剩下的功能是检查它们传递的文件描述符并设置EINVAL它是否不是伪终端的主端，因为程序可能正在做一些愚蠢的事情，比如传递非伪-这些函数的终端文件描述符并期望它们返回错误。有一段时间，在 Linux 上，伪终端从设备是持久设备节点。GNU C 库
grantpt()不是系统调用。相反，它派生并执行了一个名为 的 set-UID 帮助程序，这让没有 set-UID 可执行文件的人群pt_chown感到非常沮丧。（必须允许非特权用户更改它不一定拥有的特殊设备文件的所有权和权限，记住。）所以仍然有机会之窗，Linux 仍然必须为.grantpt()unlockpt()然而，它的“新”
devpts文件系统（其中“新”意味着几年前引入，现在）几乎允许使用与在 FreeBSD 上相同的方式做事devfs。有一些差异。devpts系统中，这是ptmx不同devtmpfs文件系统中的设备，devpts文件系统仅包含自动创建/销毁的从设备文件。传统上，该设置是/dev/ptmx和一个随附的devpts安装在/dev/pts.devpts，用于容器等，当有很多devtmpfs文件系统时，要同步（正确的）两个文件系统是相当困难的devpts。因此，在较新的“新”devpts系统中，所有设备，多路复用器和从设备，都在一个文件系统中。为了向后兼容，默认设置ptmx是无法访问新节点，除非设置了新的ptmxmode挂载选项。devpts的ptmx设备文件devpts现在是主要的多路复用器，ptmx其中devtmpfs要么是内核提供的一个 shim，它试图模仿一个符号链接，一个绑定挂载，或者一个普通的旧的实际符号链接到pts/ptmx.grantpt()应有的方式设置所有权和权限。设置错误的挂载选项（gid不是ttyGID 或mode0620）会触发 GNU C 库中的回退行为。为了grantpt()在 GNU C 库中按照需要减少到无操作，内核必须不分配打开进程的组（即必须有明确的gid设置），分配的组必须是tty组，mode新的创建的从设备必须正好是 0620。默认情况下不打开
/dev/pts/ptmx和 GNU C 库没有完全减少grantpt()到无操作都是因为内核和 C 库没有保持同步。每个都必须使用另一个旧版本。Linux 仍然必须提供较旧的/dev/ptmx.pt_chown如果没有devpts具有正确挂载选项的新文件系统，GNU C 库仍然必须返回运行。因此
unlockpt()，如果devpts挂载选项错误并且 GNU C 库因此不得不退回到实际在grantpt().进一步阅读
Documentation/filesystems/devpts.txt. Linux 内核。/dev/pts必须使用“newinstance”挂载标志来避免容器的安全问题。红帽错误 #501718。open-controlling-tty. 小吃指南。软件。vc-get-tty. 小吃指南。软件。pty-get-tty. 小吃指南。软件。