A cosa serve `/dev/console`?

/dev/console esiste principalmente per esporre la console del kernel allo spazio utente. La documentazione del kernel Linux sui dispositivi ora dice

Il dispositivo console, /dev/console , è il dispositivo a cui devono essere inviati i messaggi di sistema e su cui devono essere consentiti gli accessi in modalità utente singolo. A partire da Linux 2.1.71, /dev/console è gestito dal kernel; per le versioni precedenti dovrebbe essere un collegamento simbolico a /dev/tty0 , una console virtuale specifica come /dev/tty1 , o a una porta seriale primaria (tty* , non cu* ) dispositivo, a seconda della configurazione del sistema.

/dev/console , il nodo del dispositivo con maggiore 5 e minore 1, fornisce l'accesso a qualsiasi cosa il kernel consideri il suo mezzo principale di interazione con l'amministratore di sistema; questa può essere una console fisica connessa al sistema (con l'astrazione della console virtuale in cima, quindi può usare tty0 o qualsiasi ttyN dove N è compreso tra 1 e 63), o una console seriale, o una console hypervisor, o anche un dispositivo Braille. Nota che il kernel stesso non usa /dev/console :i nodi dei dispositivi sono per lo spazio utente, non per il kernel; tuttavia controlla che /dev/console esiste ed è utilizzabile e imposta init con i suoi standard input, output ed errore che puntano a /dev/console .

Come descritto qui, /dev/console è un dispositivo di caratteri con un maggiore e un minore fissi perché è un dispositivo separato (come in un mezzo per accedere al kernel; non un dispositivo fisico), non equivalente a /dev/tty0 o qualsiasi altro dispositivo. Questo è in qualche modo simile alla situazione con /dev/tty che è il suo dispositivo (5:0) perché fornisce funzionalità leggermente diverse rispetto alle altre console virtuali o dispositivi terminali.

La "lista di console" è in effetti l'elenco di console definito dal console= parametri di avvio (o la console predefinita, se non ce ne sono). Puoi vedere le console definite in questo modo guardando /proc/consoles . /dev/console fornisce effettivamente l'accesso all'ultimo di questi:

È possibile specificare più opzioni console=sulla riga di comando del kernel. L'output apparirà su tutti loro. L'ultimo dispositivo verrà utilizzato quando apri /dev/console .

"Che cos'è /dev/console ?" è risposto nella risposta precedente. Forse quella risposta è più chiara quando conosci le risposte alle altre due domande.

D1. "Qual è il file del dispositivo che rappresenta il terminale fisico stesso?"

Non esiste un tale file di dispositivo.

D2. "Che cos'è /dev/console usato per?"

Su Linux, /dev/console è usato per mostrare i messaggi durante l'avvio (e l'arresto). Viene utilizzato anche per la "modalità utente singolo", come sottolineato nella risposta di Stephen Kitt. Non c'è molto altro per cui abbia senso usarlo.

"Nei bei vecchi tempi" di Unix, /dev/console era un dispositivo fisico dedicato. Ma questo non è il caso di Linux.

Prove correlate

1. "Qual è il file del dispositivo che rappresenta il terminale fisico stesso?"

Fammi provare a capire in questo modo. /dev/tty{1..63} e /dev/pts/n sono file di dispositivo che rappresentano i dispositivi stessi (sebbene siano emulazioni), non in relazione al processo o al kernel. /dev/tty0 rappresenta quello in /dev/tty{1..63} che è attualmente utilizzato da qualcosa (forse il kernel o il processo della shell ?). /dev/tty rappresenta il terminale di controllo attualmente utilizzato da una sessione di processo. /dev/console rappresenta il terminale attualmente utilizzato dal kernel?

Qual è il file di dispositivo che rappresenta il terminale fisico stesso, non in relazione al kernel o al processo?

I dispositivi sottostanti per /dev/tty{1..63} sono struct con_driver . Per vedere tutti i possibili driver, controlla https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console

Non esiste alcun file di dispositivo per questi dispositivi sottostanti!

C'è solo un'interfaccia in spazio utente minimo per gestirli.

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

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

Se vuoi davvero saperne di più, il (M) sta per modulo. Cioè. il dispositivo di console fittizio non è fornito da un modulo del kernel caricabile; fa parte dell'immagine iniziale del kernel (ovvero "builtin").

In secondo luogo, il bind file in ogni sottodirectory di /sys/class/vtconsole sembra indicare quale dispositivo vtconsole è attivo. Se scrivo 0 a quello attivo, sembra passare a quello fittizio. (I VT della GUI sembrano inalterati, ma i VT del testo smettono di funzionare). Scrivendo 1 per quello fittizio non lo si attiva. Entrambi i metodi funzionano per tornare a quello reale. Se ho letto correttamente il codice, il trucco è che echo 1 > bind dovrebbe funzionare solo per i driver di console che sono compilati come modulo (?!).

Per framebuffer console in particolare, ci sono alcune informazioni in più sull'associazione di diversi dispositivi framebuffer (/dev/fb0 ...) a console virtuali specifiche in https://kernel.org/doc/Documentation/fb/fbcon.txt . Ciò implica un'opzione del kernel fbcon:map= o un comando chiamato con2fbmap .

Ovviamente i dettagli possono variare con diverse versioni del kernel, architetture, firmware, dispositivi, driver, ecc. Non ho mai dovuto usare nessuna delle interfacce di cui sopra. Il kernel consente solo i915 / inteldrmfb / come vuoi chiamarlo subentra quando si carica, sostituendo ad es. vgacon .

Sembra che la mia macchina EFI non abbia mai vgacon . Quindi in primo luogo utilizza una console fittizia e in secondo luogo dopo 1,2 secondi passa a fbcon , in esecuzione su efifb . Ma finora non mi sono dovuto preoccupare dei dettagli; funziona e basta.

$ 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. "Cos'è /dev/console usato per?"

Puoi utilizzare /dev/console come dispositivo TTY. La scrittura su di esso, ad esempio, scriverà su uno specifico dispositivo sottostante, che avrà anche un proprio numero di dispositivo di carattere.

Spesso /dev/console è legato a /dev/tty0, ma a volte può essere legato a un dispositivo diverso.

Quindi in questo caso scrivere su /dev/console scriverà su /dev/tty0. E a sua volta, scrivere su /dev/tty0 equivale a scrivere su qualsiasi dispositivo /dev/ttyN sia attualmente attivo.

Ma questo solleva una domanda interessante. Accesso a tty0 accederà a diverse console virtuali, a seconda di quale è attualmente attiva. Cosa usano realmente le persone tty0 for, e allo stesso modo cos'è console utilizzato su Linux?

1. Tecnicamente, puoi leggere e scrivere da console / tty0 , ad esempio eseguendo un getty per consentire l'accesso a tty0 . Ma questo è utile solo come trucco veloce. Perché significa che non puoi sfruttare le molteplici console virtuali di Linux.

2. systemd cerca in sysfs per un attributo associato al dispositivo /dev/console, per rilevare il dispositivo TTY sottostante. Ciò consente systemd per generare automaticamente un getty e consentire l'accesso ad es. una console seriale, quando l'utente imposta una console del kernel avviando con console=ttyS0 . Questo è conveniente; evita la necessità di configurare questa console in due luoghi diversi. Di nuovo, vedi man systemd-getty-generator . Tuttavia, systemd in realtà non apre /dev/console per questo.

3. Durante il bootstrap del sistema, potresti non avere ancora montato sysfs. Ma vuoi essere in grado di mostrare i messaggi di errore e di avanzamento il prima possibile! Quindi giriamo attorno al punto 1). Il kernel avvia il PID 1 con stdin/stdout/stderr connesso a /dev/console . È molto bello avere questo semplice meccanismo impostato fin dall'inizio.

4. All'interno di un contenitore Linux, il file in /dev/console può essere creato come qualcosa di diverso - non il numero di dispositivo del carattere 5:1 . Invece, può essere creato come file di dispositivo PTS. Quindi avrebbe senso accedere tramite questo /dev/console file. systemd all'interno di un contenitore consentirà l'accesso a tale dispositivo; vedi man systemd-getty-generator .

   Questo meccanismo viene utilizzato quando esegui un contenitore con systemd-nspawn comando. (Penso che solo quando esegui systemd-nspawn su un TTY, anche se non riesco a capirlo dalla ricerca nella pagina man).

   systemd-nspawn crea il /dev/console del contenitore come bind mount di un dispositivo PTS dall'host. Ciò significa che questo dispositivo PTS non è visibile all'interno di /dev/pts/ all'interno del contenitore.

   I dispositivi PTS sono locali per uno specifico devpts montare. I dispositivi PTS sono un'eccezione alla normale regola secondo cui i dispositivi sono identificati dal loro numero di dispositivo. I dispositivi PTS sono identificati dalla combinazione del loro numero di dispositivo e del loro devpts montare.

5. Puoi scrivere messaggi urgenti a console / tty0 , per scrivere nella console virtuale corrente dell'utente. Questo potrebbe essere utile per i messaggi di errore urgenti in spazio utente, simili ai messaggi urgenti del kernel che vengono stampati sulla console (vedi man dmesg ). Tuttavia non è comune farlo, almeno una volta che il sistema ha terminato l'avvio.

   rsyslog ha un esempio in questa pagina, che stampa i messaggi del kernel su /dev/console; questo è inutile su Linux perché il kernel lo farà già per impostazione predefinita. Un esempio che non riesco a trovare di nuovo dice che non è una buona idea usarlo per i messaggi non del kernel perché ci sono troppi messaggi syslog, riempi la tua console e si intromette troppo.

   systemd-journald ha allo stesso modo opzioni per inoltrare tutti i log alla console. In linea di principio questo potrebbe essere utile per il debug in un ambiente virtuale. Tuttavia, per il debug di solito inoltriamo a /dev/kmsg invece. Questo li salva nel buffer del log del kernel in modo che tu possa leggerli con dmesg . Come i messaggi generati dal kernel stesso, questi messaggi possono essere ritrasmessi alla console a seconda della configurazione corrente del kernel.