O antigo mecanismo AT&T System 5 para dispositivos escravos pseudoterminais era que eles eram nós de dispositivos de caracteres persistentes/dev comuns sob o . Havia um dispositivo mestre/dev/ptmx multiplexador em . O antigo mecanismo 4.3BSD para dispositivos pseudoterminais tinha pares paralelos de nós de dispositivos mestre e escravo persistentes/dev comuns sob . Estes eram nós de dispositivos especiais em um sistema de arquivos de disco comum.

No OpenBSD, parte disso ainda é verdade hoje em dia. /devainda é um volume de disco e os dispositivos escravos ainda são nós reais no disco. Eles são criados sob demanda, no entanto. O kernel emite internamente as chamadas relevantes para criar novos nós de dispositivo quando é emitido um PTMGETcontrole de E/S no /dev/ptmdispositivo.

No FreeBSD, nada disso ainda é verdade. Não existe mais um dispositivo multiplexador. /devnão é um volume de disco. É um sistema de devfsarquivos. Os dispositivos escravos aparecem no sistema de devfsarquivos sob seu pts/diretório em resposta à posix_openpt()chamada do sistema, que é uma chamada direta do sistema, não um encapsulado ioctl()em um descritor de arquivo aberto para algum dispositivo "multiplexor".

Por um tempo no Linux, os dispositivos escravos pseudoterminais eram nós de dispositivos persistentes. O que você está vendo é o seu "novo" sistema de devptsarquivos (onde "novo" significa introduzido há alguns anos atrás, agora) em conjunto com o devtmpfs. Isso quase permite a mesma maneira de fazer as coisas como no FreeBSD com devfs.

Mas existem algumas diferenças. Em particular, ainda existe um dispositivo "multiplexor".

• No sistema "novo" mais antigodevpts , este era um ptmxdispositivo em um devtmpfssistema de arquivos diferente, com o sistema de devptsarquivos contendo apenas os arquivos de dispositivos escravos criados/destruídos automaticamente. Convencionalmente, a configuração era e uma montagem /dev/ptmxacompanhante em .devpts/dev/pts
• Mas o pessoal do Linux queria ter várias instâncias totalmente independentes do sistema de devptsarquivos, para contêineres e afins, e acabou sendo bastante difícil sincronizar os dois sistemas de arquivos (corretos) quando havia muitos devtmpfs sistemas de devptsarquivos. Portanto, no sistema "novo" mais recentedevpts , todos os dispositivos, multiplexadores e escravos, estão em um sistema de arquivos.

  Para compatibilidade com versões anteriores, o padrão era que o novo ptmxnó fosse inacessível, a menos que fosse definido uma nova ptmxmodeopção de montagem. No modo de compatibilidade com versões anteriores, ainda era possível executar as coisas da maneira mais antiga de instância única, e por padrão, a menos que se usasse uma newinstanceopção explícita ao montar um arquivo devpts.

• No ainda mais novo ainda "novo" devpts(que existe desde 2016), o dispositivo multiplexador por instância no sistema de devptsarquivos agora é o multiplexador primário, e o ptmxno devtmpfsé um shim fornecido pelo kernel que tenta imitar um link simbólico, uma montagem de ligação ou um link simbólico realpts/ptmx antigo simples para . A maneira de várias instâncias agora é a única maneira.

Leitura adicional

• https://unix.stackexchange.com/a/470853/5132
• Qual seria a melhor maneira de contornar esse problema da glibc?
• https://unix.stackexchange.com/a/214685/5132
• Documentation/filesystems/devpts.txt. Núcleo Linux.
• Daniel Berrange (2009-05-20). /dev/ptsdeve usar o sinalizador de montagem 'newinstance' para evitar problemas de segurança com contêineres . Erro de chapéu vermelho #501718.
• Eric W. Biederman (2015-12-11). devpts: Sensible /dev/ptmx & force newinstance . Lista de discussão do kernel Linux.
• Eric W. Biederman (2016-04-08). devpts: Ensine /dev/ptmx a encontrar os devpts associados por meio de pesquisa de caminho . Lista de discussão do kernel Linux.