Para que serve `/dev/console`?

/dev/consoleexiste principalmente para expor o console do kernel ao espaço do usuário. A documentação do kernel Linux em dispositivos agora diz

O dispositivo do console, /dev/console, é o dispositivo para o qual as mensagens do sistema devem ser enviadas e no qual os logins devem ser permitidos no modo de usuário único. A partir do Linux 2.1.71, /dev/consoleé gerenciado pelo kernel; para versões anteriores, deve ser um link simbólico para /dev/tty0, um console virtual específico, como /dev/tty1, ou para um dispositivo de porta serial primária ( tty*, não cu*), dependendo da configuração do sistema.

/dev/console, o nó do dispositivo com maior 5 e menor 1, fornece acesso a qualquer coisa que o kernel considere ser seu principal meio de interação com o administrador do sistema; este pode ser um console físico conectado ao sistema ( com a abstração do console virtual na parte superior, então ele pode usar tty0ou qualquer N está entre 1 e 63), ou um console serial, ou um console de hipervisor, ou mesmo um dispositivo Braille. Observe que o kernel em si não usa : devices nodes são para userspace, não para o kernel; ele, no entanto, verifica se existe e é utilizável e configura com sua entrada, saída e erro padrão apontando para .ttyN/dev/console/dev/consoleinit/dev/console

Conforme descrito aqui, /dev/consoleé um dispositivo de caractere com maior e menor fixos porque é um dispositivo separado (como um meio de acessar o kernel; não um dispositivo físico), não equivalente a /dev/tty0ou qualquer outro dispositivo. Isso é um pouco semelhante à situação com o/dev/tty qual é seu próprio dispositivo (5:0) porque fornece recursos ligeiramente diferentes do outro console virtual ou dispositivos de terminal.

A “lista de consoles” é de fato a lista de consoles definida pelos console=parâmetros de inicialização (ou o console padrão, se não houver nenhum). Você pode ver os consoles definidos dessa maneira olhando para /proc/consoles. /dev/consolede fato fornece acesso ao último destes :

Você pode especificar várias opções console= na linha de comando do kernel. A saída aparecerá em todos eles. O último dispositivo será usado quando você abrir /dev/console.

"O que é /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 de dispositivo que representa o próprio terminal físico?"

Não existe tal arquivo de dispositivo.

Q2. "Para que /dev/consoleserve?"

No Linux, /dev/consoleé usado para mostrar mensagens durante a inicialização (e desligamento). Também é usado para "modo de usuário único", conforme apontado na resposta de Stephen Kitt. Não há muito mais que faça sentido usá-lo.

"Nos bons velhos tempos" do Unix, /dev/consoleera um dispositivo físico dedicado. Mas este não é o caso do Linux.

Evidência relacionada

1. "Qual é o arquivo de dispositivo que representa o próprio terminal físico?"

Deixe-me tentar entender desta forma. /dev/tty{1..63}e /dev/pts/nsão arquivos de dispositivo que representam os próprios dispositivos (embora sejam emulações), não em relação ao processo ou kernel. /dev/tty0representa aquele em /dev/tty{1..63}que está actualmente a ser 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 de 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, confira https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console

Não há arquivo de dispositivo para esses dispositivos subjacentes!

Há 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)significa módulo . Ou seja, o dispositivo de console fictício não é fornecido por um módulo de kernel carregável; é parte da imagem inicial do kernel (também conhecida como "builtin").

Em segundo lugar, o bindarquivo em cada subdiretório de /sys/class/vtconsoleaparece para informar qual dispositivo vtconsole está ativo. Se eu escrever 0para o ativo, ele parece mudar para o fictício. (Os VTs da GUI parecem não ser afetados, mas os VTs de texto param de funcionar). Escrever 1para o fictício não o ativa. Qualquer um dos métodos funciona para voltar ao real. Se eu ler o código corretamente, o truque é que echo 1 > bindsó deve funcionar para drivers de console que são construídos como um módulo (?!).

Para consoles de framebuffer especificamente, há mais algumas informações sobre como vincular diferentes dispositivos de framebuffer ( /dev/fb0...) a consoles virtuais específicos em https://kernel.org/doc/Documentation/fb/fbcon.txt . Isso envolve uma opção do 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. Eu nunca precisei usar nenhuma das interfaces acima. O kernel apenas deixa i915// inteldrmfbo que você quiser chamá-lo assumir quando ele carrega, substituindo, por exemplo, vgacon.

Parece que minha máquina EFI nunca teve arquivos vgacon. Então, em primeiro lugar, ele usa um console fictício e, em segundo lugar, após 1,2 segundos, muda para fbcon, rodando em cima de efifb. Mas até agora não precisei me importar com os detalhes; apenas 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/consoleserve?"

Você pode usar /dev/console como um dispositivo TTY. Gravar nele, por exemplo, gravará em um dispositivo subjacente específico, que também terá um número de dispositivo de caractere próprio.

Frequentemente /dev/console está vinculado a /dev/tty0, mas às vezes pode estar vinculado a um dispositivo diferente.

Portanto, neste caso, gravar em /dev/console gravará em /dev/tty0. E, por sua vez, gravar em /dev/tty0 é equivalente a gravar em qualquer dispositivo /dev/ttyN que esteja ativo no momento.

Mas isso levanta uma questão interessante. O acesso tty0acessará diferentes consoles virtuais, dependendo de qual estiver ativo no momento. Para que as pessoas realmente usam tty0e, da mesma forma, o que é consoleusado no Linux?

1. Tecnicamente, você pode ler e escrever de console/ tty0, por exemplo, executando a gettypara permitir o login em tty0. Mas isso só é útil como um hack rápido. Porque isso significa que você não pode tirar proveito dos vários consoles virtuais do Linux.

2. 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 este console em dois lugares diferentes. Novamente, veja man systemd-getty-generator. No entanto, systemdnão abre realmente /dev/consolepara isso.

3. Durante a inicialização do sistema, você pode nem ter o sysfs montado ainda. Mas você quer poder mostrar mensagens de erro e progresso o mais rápido possível! Então, circulamos até o ponto 1). O kernel inicia o PID 1 com stdin/stdout/stderr conectado a /dev/console. É muito bom ter esse mecanismo simples configurado desde o início.

4. Dentro de um container Linux, o arquivo at /dev/consolepode ser criado como algo diferente - não o caractere número do dispositivo 5:1. Em vez disso, ele pode ser criado como um arquivo de dispositivo PTS. Então faria sentido fazer login através deste /dev/consolearquivo. systemddentro de um contêiner permitirá o login em tal dispositivo; veja man systemd-getty-generator.

   Esse mecanismo é usado quando você executa um contêiner com o systemd-nspawncomando. (Acho que apenas quando você executa systemd-nspawnem um TTY, embora não possa dizer pesquisando na página de manual).

   systemd-nspawncria o contêiner /dev/consolecomo uma montagem de ligação de um dispositivo PTS do host. Isso significa que este dispositivo PTS não é visível dentro /dev/pts/do contêiner.

   Os dispositivos PTS são locais para uma devptsmontagem específica. Os dispositivos PTS são uma exceção à regra normal, de que os dispositivos são identificados pelo número do dispositivo. Os dispositivos PTS são identificados pela combinação de seu número de dispositivo e sua devptsmontagem.

5. 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 do espaço do usuário, semelhantes às mensagens urgentes do kernel que são impressas no console (consulte Recursos man dmesg). No entanto, não é comum fazer isso, pelo menos depois que o sistema terminar de inicializar.

   rsyslog tem um exemplo nesta página , que imprime mensagens do kernel para /dev/console; isso é inútil no Linux porque o kernel já fará isso por padrão. Um exemplo que não consigo encontrar novamente diz que não é uma boa ideia usar isso para mensagens não-kernel porque há muitas mensagens syslog, você inunda seu console e isso atrapalha muito.

   O systemd-journald também tem 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 /dev/kmsg. Isso os salva no buffer de log do kernel para que você possa lê-los com dmesg. Assim como as mensagens geradas pelo próprio kernel, essas mensagens podem ecoar no console dependendo da configuração atual do kernel.