"O que é isso /dev/console?" é respondido na resposta anterior . Talvez essa resposta seja mais clara quando você souber as respostas para as outras duas perguntas.
Q1 "Qual é o arquivo do dispositivo que representa o próprio terminal físico?"
Não existe esse arquivo de dispositivo.
Q2 "Para que é /dev/consoleusado?"
No Linux, /dev/consoleé usado para mostrar mensagens durante a inicialização (e o desligamento). Também é usado para o "modo monousuário", como apontado na resposta de Stephen Kitt. Não há muito mais para fazer sentido usá-lo.
"Nos bons velhos tempos" do Unix, /dev/consoleera um dispositivo físico dedicado. Mas este não é o caso no Linux.
Evidência relacionada
1. "Qual é o arquivo do dispositivo que representa o próprio terminal físico?"
Deixe-me tentar entender dessa maneira. /dev/tty{1..63}e /dev/pts/nsão arquivos de dispositivos representando os próprios dispositivos (embora sejam emulações), não em relação ao processo ou ao kernel. /dev/tty0representa aquele em /dev/tty{1..63}que atualmente é usado por algo (talvez o kernelou processo de shell?). /dev/ttyrepresenta o terminal de controle atualmente usado por uma sessão de processo. /dev/consolerepresenta o terminal atualmente usado pelo kernel?
Qual é o arquivo do dispositivo que representa o próprio terminal físico, não em relação ao kernel ou processo?
O (s) dispositivo (s) subjacente (s) para /dev/tty{1..63}são struct con_driver. Para ver todos os drivers possíveis, consulte https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console
Não há arquivo de dispositivo para esses dispositivos subjacentes!
Existe apenas uma interface de espaço de usuário mínima para gerenciá-los.
$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device
==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device
Se você realmente quer saber mais, o (M)módulo significa . Ou seja, o dispositivo do console fictício não é fornecido por um módulo do kernel carregável; faz parte da imagem inicial do kernel (aka "builtin").
Em segundo lugar, o bindarquivo em cada subdiretório de /sys/class/vtconsoleaparece para informar qual dispositivo vtconsole está ativo. Se eu escrevo 0no ativo, ele parece mudar para o falso. (VTs da GUI parecem inalterados, mas os VTs de texto param de funcionar). Escrever 1para o manequim não o ativa. Qualquer um dos métodos funciona para voltar ao real. Se eu li o código corretamente, o truque é que ele echo 1 > binddeve funcionar apenas para drivers de console que são construídos como um módulo (?!).
Para consoles framebuffer especificamente, há mais informações sobre como vincular diferentes dispositivos framebuffer ( /dev/fb0...) a consoles virtuais específicos em https://kernel.org/doc/Documentation/fb/fbcon.txt . Isso envolve uma opção de kernel fbcon:map=ou um comando chamado con2fbmap.
É claro que os detalhes podem variar de acordo com as diferentes versões do kernel, arquiteturas, firmwares, dispositivos, drivers, etc. Nunca tive que usar nenhuma das interfaces acima. O kernel apenas deixa i915/ inteldrmfb/ como você quiser chamá-lo quando ele é carregado, substituindo, por exemplo vgacon.
Parece que minha máquina EFI nunca foi vgacon. Então, primeiro, ele usa um console fictício e, em seguida, após 1,2 segundos, ele muda para fbcon, rodando em cima de efifb. Mas até agora não precisei me importar com os detalhes; simplesmente funciona.
$ dmesg | grep -C2 [Cc]onsole
[ 0.230822] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.233164] NR_IRQS: 65792, nr_irqs: 728, preallocated irqs: 16
[ 0.233346] Console: colour dummy device 80x25
[ 0.233571] console [tty0] enabled
[ 0.233585] ACPI: Core revision 20180810
[ 0.233838] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
--
[ 1.228393] efifb: scrolling: redraw
[ 1.228396] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 1.230393] Console: switching to colour frame buffer device 170x48
[ 1.232090] fb0: EFI VGA frame buffer device
[ 1.232110] intel_idle: MWAIT substates: 0x11142120
--
[ 3.595838] checking generic (e0000000 408000) vs hw (e0000000 10000000)
[ 3.595839] fb: switching to inteldrmfb from EFI VGA
[ 3.596577] Console: switching to colour dummy device 80x25
[ 3.596681] [drm] Replacing VGA console driver
[ 3.597159] [drm] ACPI BIOS requests an excessive sleep of 20000 ms, using 1500 ms instead
[ 3.599830] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
--
[ 3.657050] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[ 3.657869] e1000e 0000:00:19.0 eno1: renamed from eth0
[ 4.711453] Console: switching to colour frame buffer device 170x48
[ 4.734356] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 4.778813] Loading iSCSI transport class v2.0-870.
2. "Para que é /dev/consoleutilizado?"
Você pode usar / dev / console como um dispositivo TTY. Escrever nele, por exemplo, gravará em um dispositivo subjacente específico, que também terá um número de dispositivo de caractere próprio.
Freqüentemente / dev / console está vinculado a / dev / tty0, mas às vezes pode estar vinculado a um dispositivo diferente.
Portanto, neste caso, escrever para / dev / console escreverá para / dev / tty0. Por sua vez, gravar em / dev / tty0 equivale a gravar em qualquer dispositivo / dev / ttyN atualmente ativo.
Mas isso levanta uma questão interessante. O acesso tty0acessará diferentes consoles virtuais, dependendo de qual está ativo no momento. Para que as pessoas realmente usam tty0e da mesma forma que são consoleusadas no Linux?
Tecnicamente, você pode ler e gravar em console/ tty0, por exemplo, executando a gettypara permitir o login tty0. Mas isso é útil apenas como um hack rápido. Porque isso significa que você não pode tirar proveito dos vários consoles virtuais do Linux.
systemdprocura sysfsum atributo associado ao dispositivo / dev / console, para detectar o dispositivo TTY subjacente. Isso permite systemdgerar automaticamente um gettye permitir o login, por exemplo, em um console serial, quando o usuário configura um console do kernel, inicializando com console=ttyS0. Isso é conveniente; evita a necessidade de configurar esse console em dois lugares diferentes. Mais uma vez, veja man systemd-getty-generator. No entanto, systemdnão é realmente aberto /dev/consolepara isso.
Durante a inicialização do sistema, talvez você nem tenha o sysfs montado ainda. Mas você deseja poder mostrar mensagens de erro e progresso o mais rápido possível! Então, circulamos para o ponto 1). O kernel inicia o PID 1 com stdin / stdout / stderr conectado /dev/console. É muito bom ter esse mecanismo simples configurado desde o início.
Dentro de um contêiner Linux, o arquivo em /dev/consolepode ser criado como algo diferente - não o número do dispositivo do caractere 5:1. Em vez disso, ele pode ser criado como um arquivo de dispositivo PTS. Então, faria sentido fazer logon nesse /dev/consolearquivo. systemddentro de um contêiner permitirá o login em um dispositivo desse tipo; veja man systemd-getty-generator.
Este mecanismo é usado quando você executa um contêiner com o systemd-nspawncomando (Acho que apenas quando você executa systemd-nspawnum TTY, embora não seja possível pesquisar na página de manual).
systemd-nspawncria o contêiner /dev/consolecomo uma montagem de ligação de um dispositivo PTS a partir do host. Isso significa que este dispositivo PTS não é visível /dev/pts/dentro do contêiner.
Os dispositivos PTS são locais para uma devptsmontagem específica . Os dispositivos PTS são uma exceção à regra normal, que os dispositivos são identificados pelo seu número de dispositivo. Os dispositivos PTS são identificados pela combinação do número do dispositivo e da devptsmontagem.
Você pode gravar mensagens urgentes em console/ tty0, para gravar no console virtual atual do usuário. Isso pode ser útil para mensagens de erro urgentes no espaço do usuário, semelhantes às mensagens urgentes do kernel que são impressas no console (consulte man dmesg). No entanto, não é comum fazer isso, pelo menos uma vez que o sistema tenha finalizado a inicialização.
O rsyslog possui um exemplo nesta página , que imprime mensagens do kernel para /dev/console; isso não faz sentido no Linux, porque o kernel já o fará por padrão. Um exemplo que não consigo encontrar novamente diz que não é uma boa ideia usá-lo para mensagens que não são do kernel, porque há muitas mensagens syslog, você inunda seu console e isso atrapalha demais.
O systemd-journald também possui opções para encaminhar todos os logs para o console. Em princípio, isso pode ser útil para depuração em um ambiente virtual. Embora, para depuração, geralmente encaminhamos para o /dev/kmsginvés. Isso os salva no buffer de log do kernel para que você possa lê-los com dmesg. Como as mensagens geradas pelo próprio kernel, essas mensagens podem ser exibidas no console, dependendo da configuração atual do kernel.