"Qu'est-ce que c'est /dev/console?" est répondu dans la réponse précédente . Cette réponse est peut-être plus claire lorsque vous connaissez les réponses aux deux autres questions.
Q1. "Quel est le fichier du périphérique représentant le terminal physique lui-même?"
Il n'y a pas un tel fichier de périphérique.
Q2. "A quoi ça /dev/consolesert?"
Sous Linux, /dev/consoleest utilisé pour afficher des messages lors du démarrage (et de l'arrêt). Il est également utilisé pour le "mode mono-utilisateur", comme l'a souligné la réponse de Stephen Kitt. Il n'y a pas grand-chose d'autre pour lequel il est logique de l'utiliser.
"Au bon vieux temps" d'Unix, /dev/consoleétait un appareil physique dédié. Mais ce n'est pas le cas sous Linux.
Preuve connexe
1. "Quel est le fichier d'appareil représentant le terminal physique lui-même?"
Permettez-moi d'essayer de comprendre de cette façon. /dev/tty{1..63}et /dev/pts/nsont des fichiers de périphériques représentant des périphériques eux-mêmes (bien qu'ils soient des émulations), sans relation avec le processus ou le noyau. /dev/tty0représente celui dans /dev/tty{1..63}lequel est actuellement utilisé par quelque chose (peut-être le noyauou processus shell?). /dev/ttyreprésente le terminal de contrôle actuellement utilisé par une session de processus. /dev/consolereprésente le terminal actuellement utilisé par le noyau?
Quel est le fichier de périphérique représentant le terminal physique lui-même, sans rapport avec le noyau ou le processus?
Le ou les périphériques sous-jacents /dev/tty{1..63}sont struct con_driver. Pour voir tous les pilotes possibles, consultez https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console
Il n'y a pas de fichier de périphérique pour ces périphériques sous-jacents!
Il n'y a qu'une interface d'espace utilisateur minimale pour les gérer.
$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device
==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device
Si vous voulez vraiment en savoir plus, le (M)module signifie . C'est-à-dire que la console factice n'est pas fournie par un module noyau chargeable; il fait partie de l'image initiale du noyau (aka "builtin").
Deuxièmement, le bindfichier de chaque sous-répertoire de /sys/class/vtconsoleapparaît pour vous indiquer quel périphérique vtconsole est actif. Si j'écris 0sur celui qui est actif, il semble basculer sur celui factice. (Les VT GUI ne semblent pas affectés, mais les VT texte ne fonctionnent plus). Écrire 1pour le mannequin ne l’active pas. L'une ou l'autre méthode fonctionne pour revenir à la vraie. Si je lis le code correctement, l'astuce est que cela echo 1 > bindne devrait fonctionner que pour les pilotes de console qui sont construits en tant que module (?!).
Pour les consoles framebuffer en particulier, il y a plus d'informations sur la liaison de différents périphériques framebuffer ( /dev/fb0...) à des consoles virtuelles spécifiques dans https://kernel.org/doc/Documentation/fb/fbcon.txt . Cela implique une option du noyau fbcon:map=ou une commande appelée con2fbmap.
Bien sûr, les détails peuvent varier selon les différentes versions du noyau, architectures, firmwares, périphériques, pilotes, etc. Je n'ai jamais vraiment eu à utiliser l'une des interfaces ci-dessus. Le noyau laisse juste i915/ inteldrmfb/ ce que vous voulez l'appeler prendre le relais lors du chargement, en remplaçant par exemple vgacon.
On dirait que ma machine EFI ne l'a jamais fait vgacon. Donc, premièrement, il utilise une console factice, et deuxièmement après 1,2 seconde, il passe à fbcon, en cours d'exécution efifb. Mais jusqu'à présent, je n'ai pas eu à me soucier des détails; ça marche juste.
$ 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. "À quoi /dev/consolesert-on?"
Vous pouvez utiliser / dev / console comme périphérique TTY. L'écriture, par exemple, écrit sur un périphérique sous-jacent spécifique, qui aura également un numéro de périphérique de caractère qui lui est propre.
Souvent / dev / console est lié à / dev / tty0, mais parfois il peut être lié à un périphérique différent.
Donc dans ce cas, écrire dans / dev / console va écrire dans / dev / tty0. Et à son tour, écrire dans / dev / tty0 équivaut à écrire dans le périphérique / dev / ttyN actuellement actif.
Mais cela soulève une question intéressante. L' tty0accès permettra d'accéder à différentes consoles virtuelles, selon celle qui est actuellement active. À quoi servent les gens tty0et à quoi consolesert-on sous Linux?
Techniquement, vous pouvez lire et écrire à partir de console/ tty0, par exemple en exécutant un gettypour autoriser la connexion tty0. Mais cela n'est utile que comme hack rapide. Parce que cela signifie que vous ne pouvez pas profiter des multiples consoles virtuelles de Linux.
systemdrecherche sysfsun attribut associé au périphérique / dev / console pour détecter le périphérique TTY sous-jacent. Cela permet systemdde générer automatiquement un gettyet autoriser la connexion, par exemple sur une console série, lorsque l'utilisateur configure une console du noyau en démarrant avec console=ttyS0. C'est pratique; cela évite d'avoir à configurer cette console à deux endroits différents. Encore une fois, voyez man systemd-getty-generator. Cependant, systemdne s'ouvre pas réellement /dev/consolepour cela.
Pendant l'amorçage du système, il se peut que vous n'ayez même pas encore monté sysfs. Mais vous voulez pouvoir afficher les messages d'erreur et de progression dès que possible! Nous tournons donc autour du point 1). Le noyau démarre le PID 1 avec stdin / stdout / stderr connecté à /dev/console. C'est très agréable d'avoir ce mécanisme simple mis en place dès le départ.
Dans un conteneur Linux, le fichier at /dev/consolepeut être créé avec quelque chose de différent - pas le numéro de périphérique de caractère 5:1. Au lieu de cela, il peut être créé en tant que fichier de périphérique PTS. Il serait alors judicieux de se connecter via ce /dev/consolefichier. systemdà l'intérieur d'un conteneur permettra de se connecter sur un tel appareil; voir man systemd-getty-generator.
Ce mécanisme est utilisé lorsque vous exécutez un conteneur avec la systemd-nspawncommande. (Je pense que lorsque vous utilisez systemd-nspawnun ATS, bien que je ne puisse pas le dire en recherchant la page de manuel).
systemd-nspawncrée le conteneur en /dev/consoletant que montage de liaison d'un périphérique PTS à partir de l'hôte. Cela signifie que ce dispositif PTS n'est pas visible à l' /dev/pts/intérieur du conteneur.
Les périphériques PTS sont locaux sur un devptssupport spécifique . Les appareils PTS sont une exception à la règle normale, selon laquelle les appareils sont identifiés par leur numéro d'appareil. Les appareils PTS sont identifiés par la combinaison de leur numéro d'appareil et de leur devptssupport.
Vous pouvez écrire des messages urgents dans console/ tty0, pour écrire dans la console virtuelle actuelle de l'utilisateur. Cela pourrait être utile pour les messages d'erreur urgents de l'espace utilisateur, similaires aux messages urgents du noyau qui sont imprimés sur la console (voir man dmesg). Cependant, il n'est pas courant de le faire, au moins une fois que le système a terminé le démarrage.
rsyslog a un exemple sur cette page , qui imprime les messages du noyau à /dev/console; cela est inutile sous Linux car le noyau le fera déjà par défaut. Un exemple que je ne trouve pas encore dit que ce n'est pas une bonne idée de l'utiliser pour des messages non-noyau car il y a juste trop de messages syslog, vous inonder votre console et cela gêne trop.
systemd-journald a également des options pour transférer tous les journaux vers la console. En principe, cela peut être utile pour le débogage dans un environnement virtuel. Cependant, pour le débogage, nous transmettons généralement à la /dev/kmsgplace. Cela les enregistre dans le tampon de journal du noyau afin que vous puissiez les lire avec dmesg. Comme les messages générés par le noyau lui-même, ces messages peuvent être répercutés sur la console en fonction de la configuration actuelle du noyau.