O dispositivo mestre parece um arquivo de dispositivo de terminal, completo com uma disciplina de linha que pode ser acessada por meio de tcgetattr() / tcsetattr() / & c. e um resultado de sucesso de isatty() . Na verdade, é a mesma instância de disciplina de linha que o dispositivo escravo, e é assim que o programa no lado mestre transmite coisas como alterações no tamanho da janela para os programas no lado do escravo. É também como o programa do lado mestre sinaliza (uma emulação) o desligamento do modem, definindo a velocidade da linha para zero e, assim, acionando o mecanismo de desligamento da disciplina de linha. (O que o texto diz sobre a velocidade da linha é, portanto, incorreto. Há um caso em que a velocidade da linha é significativa.)
A diferença está na E / S de leitura / gravação. O que é lido é a sequência de caracteres que, para um terminal real, seria enviada por um dispositivo serial subjacente real. O que está escrito é a sequência de caracteres que, para um terminal real, é recebida pelo dispositivo serial subjacente real. Em outras palavras: é o outro lado do processamento de entrada e saída canônico / não canônico pela disciplina de linha.
Existem complexidades para isso, ou seja, modo de pacote e modo remoto . Este último já caiu em desuso desde então e não existia na maioria dos sistemas operacionais, mesmo no início deste século, necessitando de remendos para as antigas ferramentas de Daniel J. Bernstein. O primeiro não é particularmente útil para a maioria das tarefas e, portanto, não vou abordá-lo detalhadamente nesta resposta.
O dispositivo mestre geralmente não é o terminal de controle para as sessões nas quais os processos do lado mestre são executados. Isso seria conceitualmente colocar coisas que são análogas aos internos de um terminal real no lugar errado. O terminal de controle para tais sessões é, se estiver lá, um terminal outro .
Este será o caso de programas como script , :terminal , emacs e ptybandage do NeoVIM (se não forem parte de um pipeline), que renderizam diretamente para outro dispositivo terminal e são executados em uma sessão interativa. controlado por esse dispositivo terminal.
Não é o caso de um servidor SSH, emuladores de terminal GUI, console-terminal-emulator do conjunto de ferramentas, ptyrun (em uso normal) ou emuladores de terminal de framebuffer monolítico, como zhcon. Eles são renderizados para todos os tipos de diferentes dispositivos de E / S, desde buffers e FIFOs no sistema de arquivos no caso de console-terminal-emulator através de soquetes TCP para framebuffer e dispositivos de classe HID, nenhum dos quais são terminais. Além disso, console-terminal-emulator , servidores SSH e emuladores de terminal framebuffer são geralmente invocados em contextos de onde, naturalmente, não há terminal de controle para a sessão começar.
Observe que o diagrama não é definitivo. Não é necessariamente o caso que o processo do lado mestre forks os processos do lado do escravo. Em terminais virtuais de espaço de usuário nosets-toolset, por exemplo, os processos do lado do escravo são ttylogin@* serviços comuns, bifurcados pelo gerenciador de serviços, e não há relação de processo direta entre o processo do emulador no lado mestre e a sessão de login processos no lado do escravo. Mas isso está indo além do escopo desta resposta.
Leitura adicional
- link
- link
- Jonathan de Boyne Pollard (2018). "terminais virtuais do espaço do usuário" . Guia nosh . 1,38. nosh. Softwares JdeBP's.
- Jonathan de Boyne Pollard (2018). Uma rápida olhada nos terminais virtuais do espaço do usuário nosh. Softwares JdeBP's.