¿Para qué se usa `/dev/console`?

Déjame tratar de entender de esta manera. /dev/tty{1..63} y /dev/pts/n son archivos de dispositivos que representan los propios dispositivos (aunque son emulaciones), no en relación con el proceso o el kernel. /dev/tty0 representa el de /dev/tty{1..63} que está siendo utilizado actualmente por algo (quizás kernel o proceso de shell ?). /dev/tty representa el terminal de control utilizado actualmente por una sesión de proceso. /dev/console representa el terminal actualmente utilizado por el kernel?

¿Cuál es el archivo del dispositivo que representa el terminal físico en sí mismo, no en relación con el kernel o el proceso?

Los dispositivos subyacentes para /dev/tty{1..63} son struct con_driver . Para ver todos los controladores posibles, consulte https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console

¡No hay ningún archivo de dispositivo para estos dispositivos subyacentes!

Solo hay una interfaz mínima de espacio de usuario para administrarlos.

$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device

==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device

Si realmente quieres saber más, el (M) significa módulo. Es decir. el dispositivo de consola ficticia no lo proporciona un módulo de kernel cargable; es parte de la imagen inicial del núcleo (también conocida como "integrada").

En segundo lugar, el bind archivo en cada subdirectorio de /sys/class/vtconsole aparece para decirle qué dispositivo vtconsole está activo. Si escribo 0 al activo, parece cambiar al ficticio. (Los VT de GUI parecen no verse afectados, pero los VT de texto dejan de funcionar). Escribiendo 1 para el ficticio no lo activa. Cualquiera de los métodos funciona para volver al real. Si leí el código correctamente, el truco es que echo 1 > bind se supone que solo funciona para controladores de consola que están construidos como un módulo (?!).

Para búfer de fotogramas consolas específicamente, hay más información sobre la vinculación de diferentes dispositivos framebuffer (/dev/fb0 ...) a consolas virtuales específicas en https://kernel.org/doc/Documentation/fb/fbcon.txt. Esto implica una opción de kernel fbcon:map= o un comando llamado con2fbmap .

Por supuesto, los detalles pueden variar con las diferentes versiones del núcleo, arquitecturas, firmware, dispositivos, controladores, etc. Realmente nunca tuve que usar ninguna de las interfaces anteriores. El kernel solo permite i915 / inteldrmfb / como quieras llamarlo, toma el control cuando se carga, reemplazando, p. vgacon .

Parece que mi máquina EFI nunca tiene vgacon . Entonces, en primer lugar, usa una consola ficticia y, en segundo lugar, después de 1,2 segundos, cambia a fbcon , ejecutándose sobre efifb . Pero hasta ahora no me ha tenido que importar cuáles son los detalles; simplemente 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. "¿Qué es /dev/console para qué?"

Puede usar /dev/console como dispositivo TTY. Al escribir en él, por ejemplo, se escribirá en un dispositivo subyacente específico, que también tendrá un número de dispositivo de carácter propio.

A menudo, /dev/console está vinculado a /dev/tty0, pero a veces puede estar vinculado a un dispositivo diferente.

Entonces, en este caso, escribir en /dev/console escribirá en /dev/tty0. Y a su vez, escribir en /dev/tty0 es equivalente a escribir en cualquier dispositivo /dev/ttyN que esté actualmente activo.

Pero esto plantea una pregunta interesante. Accediendo a tty0 accederá a diferentes consolas virtuales, dependiendo de cuál esté actualmente activa. ¿Qué usa realmente la gente tty0? para, y de manera similar qué es console utilizado para en Linux?

1. Técnicamente, puedes leer y escribir desde console / tty0 , por ejemplo ejecutando un getty para permitir iniciar sesión en tty0 . Pero esto solo es útil como un truco rápido. Porque significa que no puede aprovechar las múltiples consolas virtuales de Linux.

2. systemd busca en sysfs para un atributo asociado con el dispositivo /dev/console, para detectar el dispositivo TTY subyacente. Esto permite systemd para generar automáticamente un getty y permitir iniciar sesión en, p. una consola serial, cuando el usuario configuró una consola kernel iniciando con console=ttyS0 . Esto es conveniente; evita la necesidad de configurar esta consola en dos lugares diferentes. Nuevamente, vea man systemd-getty-generator . Sin embargo, systemd en realidad no abre /dev/console por esto.

3. Durante el arranque del sistema, es posible que aún no tenga sysfs montados. ¡Pero desea poder mostrar mensajes de error y progreso lo antes posible! Así que damos la vuelta al punto 1). El núcleo inicia PID 1 con stdin/stdout/stderr conectado a /dev/console . Es muy bueno tener este mecanismo simple configurado desde el principio.

4. Dentro de un contenedor de Linux, el archivo en /dev/console puede crearse como algo diferente, no como el número de dispositivo de caracteres 5:1 . En su lugar, puede crearse como un archivo de dispositivo PTS. Entonces tendría sentido iniciar sesión a través de este /dev/console expediente. systemd dentro de un contenedor permitirá iniciar sesión en dicho dispositivo; ver man systemd-getty-generator .

   Este mecanismo se usa cuando ejecuta un contenedor con el systemd-nspawn dominio. (Creo que solo cuando ejecutas systemd-nspawn en un TTY, aunque no puedo decirlo al buscar en la página del manual).

   systemd-nspawn crea el /dev/console del contenedor como un montaje de enlace de un dispositivo PTS desde el host. Esto significa que este dispositivo PTS no está visible dentro de /dev/pts/ dentro del contenedor.

   Los dispositivos PTS son locales para un devpts específico montar. Los dispositivos PTS son una excepción a la regla normal, que los dispositivos se identifican por su número de dispositivo. Los dispositivos PTS se identifican por la combinación de su número de dispositivo y su devpts montar.

5. Puedes escribir mensajes urgentes al console / tty0 , para escribir en la consola virtual actual del usuario. Esto podría ser útil para los mensajes de error urgentes del espacio de usuario, similares a los mensajes urgentes del kernel que se imprimen en la consola (ver man dmesg ). Sin embargo, no es común hacer esto, al menos una vez que el sistema ha terminado de iniciarse.

   rsyslog tiene un ejemplo en esta página, que imprime mensajes del kernel en /dev/console; esto no tiene sentido en Linux porque el núcleo ya lo hará de forma predeterminada. Un ejemplo que no puedo volver a encontrar dice que no es una buena idea usar esto para mensajes que no son del kernel porque hay demasiados mensajes de syslog, inundas tu consola y esto interfiere demasiado.

   systemd-journald también tiene opciones para reenviar todos los registros a la consola. En principio, esto podría ser útil para la depuración en un entorno virtual. Aunque, para la depuración, generalmente reenviamos a /dev/kmsg en cambio. Esto los guarda en el búfer de registro del kernel para que pueda leerlos con dmesg . Al igual que los mensajes generados por el kernel mismo, estos mensajes pueden enviarse como eco a la consola dependiendo de la configuración actual del kernel.