"Was ist /dev/console
?" wird in der vorherigen Antwort beantwortet . Vielleicht ist diese Antwort klarer, wenn Sie die Antworten auf die beiden anderen Fragen kennen.
Q1. "Was ist die Gerätedatei, die das physische Terminal selbst darstellt?"
Es gibt keine solche Gerätedatei.
Q2. "Wofür wird es /dev/console
verwendet?"
Unter Linux werden /dev/console
Meldungen beim Starten (und Herunterfahren) angezeigt. Es wird auch für den "Einzelbenutzermodus" verwendet, wie in Stephen Kitts Antwort ausgeführt. Es gibt nicht viel anderes, wofür es Sinn macht, es zu benutzen.
"In den guten alten Tagen" von Unix /dev/console
war ein dediziertes physisches Gerät. Dies ist jedoch unter Linux nicht der Fall.
Verwandte Beweise
1. "Was ist die Gerätedatei, die das physische Terminal selbst darstellt?"
Lassen Sie mich versuchen, das so zu verstehen. /dev/tty{1..63}
und /dev/pts/n
sind Gerätedateien, die Geräte selbst darstellen (obwohl es sich um Emulationen handelt), nicht in Bezug auf den Prozess oder den Kernel. /dev/tty0
stellt den dar, in /dev/tty{1..63}
dem gerade etwas verwendet wird (vielleicht Kerneloder Shell-Prozess?). /dev/tty
Stellt das steuernde Terminal dar, das derzeit von einer Prozesssitzung verwendet wird. /dev/console
Stellt das Terminal dar, das derzeit vom Kernel verwendet wird?
Was ist die Gerätedatei, die das physische Terminal selbst darstellt, nicht in Bezug auf den Kernel oder den Prozess?
Die zugrunde liegenden Geräte für /dev/tty{1..63}
sind struct con_driver
. Informationen zu allen möglichen Treibern finden Sie unter https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console
Es gibt keine Gerätedatei für diese zugrunde liegenden Geräte!
Es gibt nur eine minimale Benutzeroberfläche, um sie zu verwalten.
$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device
==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device
Wenn Sie wirklich mehr wissen wollen, das (M)
steht für Modul . Dh das Dummy-Konsolengerät wird nicht von einem ladbaren Kernelmodul bereitgestellt; Es ist Teil des ursprünglichen Kernel-Images (auch "builtin" genannt).
Zweitens zeigt die bind
Datei in jedem Unterverzeichnis von /sys/class/vtconsole
an, welches vtconsole-Gerät aktiv ist. Wenn ich 0
auf das aktive schreibe , scheint es auf das Dummy umzuschalten. (GUI-VTs scheinen nicht betroffen zu sein, Text-VTs funktionieren jedoch nicht mehr). Schreiben 1
für den Dummy aktiviert ihn nicht. Beide Methoden funktionieren, um zum realen zurückzukehren. Wenn ich den Code richtig gelesen habe, sollte der Trick echo 1 > bind
nur für Konsolentreiber funktionieren, die als Modul (?!) Erstellt wurden.
Speziell für Framebuffer- Konsolen finden Sie unter https://kernel.org/doc/Documentation/fb/fbcon.txt weitere Informationen zum Binden verschiedener Framebuffer-Geräte ( /dev/fb0
...) an bestimmte virtuelle Konsolen . Dies beinhaltet eine Kernel-Option oder einen aufgerufenen Befehl .fbcon:map=
con2fbmap
Natürlich können die Details mit verschiedenen Kernelversionen, Architekturen, Firmwares, Geräten, Treibern usw. variieren. Ich musste nie wirklich eine der obigen Schnittstellen verwenden. Der Kernel lässt einfach i915
/ inteldrmfb
/, was auch immer Sie es aufrufen möchten, übernehmen, wenn es geladen wird, und ersetzt z vgacon
.
Es sieht so aus, als hätte meine EFI-Maschine nie welche vgacon
. Also erstens verwendet es eine Dummy - Konsole, und zweitens nach 1,2 Sekunden schaltet er auf fbcon
, läuft auf der Oberseite efifb
. Aber bis jetzt musste ich mich nicht darum kümmern, was die Details sind; es funktioniert einfach.
$ 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. "Wofür wird /dev/console
verwendet?"
Sie können / dev / console als TTY-Gerät verwenden. Wenn Sie beispielsweise darauf schreiben, wird auf ein bestimmtes zugrunde liegendes Gerät geschrieben, das auch eine eigene Zeichengerätenummer hat.
Oft ist / dev / console an / dev / tty0 gebunden, aber manchmal kann es auch an ein anderes Gerät gebunden sein.
In diesem Fall wird beim Schreiben nach / dev / console nach / dev / tty0 geschrieben. Das Schreiben in / dev / tty0 entspricht dem Schreiben in das derzeit aktive / dev / ttyN-Gerät.
Dies wirft jedoch eine interessante Frage auf. Durch den Zugriff tty0
werden verschiedene virtuelle Konsolen aufgerufen, je nachdem, welche gerade aktiv sind. Wofür verwenden die Leute eigentlich tty0
und was wird console
auf Linux verwendet?
Technisch gesehen können Sie von console
/ aus lesen und schreiben tty0
, z. B. a ausführen getty
, um das Anmelden zu ermöglichen tty0
. Dies ist jedoch nur als schneller Hack nützlich. Da dies bedeutet, dass Sie die mehreren virtuellen Konsolen von Linux nicht nutzen können.
systemd
sucht sysfs
nach einem Attribut, das dem Gerät / dev / console zugeordnet ist, um das zugrunde liegende TTY-Gerät zu erkennen. Dies ermöglicht es systemd
, automatisch eine zu erzeugen getty
und sich zB an einer seriellen Konsole anzumelden, wenn der Benutzer eine Kernel-Konsole durch Booten mit einrichtet console=ttyS0
. Das ist praktisch; Sie müssen diese Konsole nicht an zwei verschiedenen Orten konfigurieren. Wieder sehen man systemd-getty-generator
. Öffnet systemd
sich aber eigentlich nicht /dev/console
dafür.
Während des System-Bootstraps ist möglicherweise noch nicht einmal sysfs aktiviert. Sie möchten aber möglichst bald Fehler- und Fortschrittsmeldungen anzeigen können! Wir kreisen also um Punkt 1). Der Kernel startet PID 1 mit stdin / stdout / stderr /dev/console
. Es ist sehr schön, diesen einfachen Mechanismus von Anfang an einzurichten.
In einem Linux-Container kann die Datei /dev/console
unter als etwas anderes erstellt werden - nicht als Zeichen für die Gerätenummer 5:1
. Stattdessen kann es als PTS-Gerätedatei erstellt werden. Dann ist es sinnvoll, sich über diese /dev/console
Datei anzumelden . systemd
In einem Container können Sie sich auf einem solchen Gerät anmelden. sehen man systemd-getty-generator
.
Dieser Mechanismus wird verwendet, wenn Sie einen Container mit dem systemd-nspawn
Befehl ausführen . (Ich denke nur, wenn Sie systemd-nspawn
auf einem TTY laufen , obwohl ich von der Suche in der Manpage nicht unterscheiden kann).
systemd-nspawn
Erstellt den Container /dev/console
als Bindemount eines PTS-Geräts vom Host. Dies bedeutet, dass dieses PTS-Gerät im /dev/pts/
Inneren des Behälters nicht sichtbar ist .
PTS-Geräte sind lokal für ein bestimmtes devpts
Mount. PTS-Geräte sind eine Ausnahme von der normalen Regel, dass Geräte anhand ihrer Gerätenummer identifiziert werden. PTS-Geräte werden durch die Kombination ihrer Gerätenummer und ihrer devpts
Halterung identifiziert .
Sie können dringende Nachrichten an console
/ tty0
schreiben, um in die aktuelle virtuelle Konsole des Benutzers zu schreiben. Dies kann für dringende Benutzerbereichsfehlermeldungen nützlich sein, ähnlich wie dringende Kernelmeldungen, die an die Konsole gesendet werden (siehe man dmesg
). Es ist jedoch nicht üblich, dies zu tun, sobald das System gebootet ist.
rsyslog hat ein Beispiel auf dieser Seite , in dem Kernelnachrichten ausgegeben werden /dev/console
. Dies ist unter Linux sinnlos, da der Kernel dies standardmäßig bereits tut. Ein Beispiel, das ich nicht wiederfinden kann, besagt, dass es keine gute Idee ist, dies für Nicht-Kernel-Nachrichten zu verwenden, da es einfach zu viele Syslog-Nachrichten gibt, Sie Ihre Konsole überfluten und es zu viel im Wege steht.
systemd-journald bietet ebenfalls Optionen zum Weiterleiten aller Protokolle an die Konsole. Im Prinzip kann dies zum Debuggen in einer virtuellen Umgebung hilfreich sein. Für das Debuggen leiten wir jedoch normalerweise an weiter /dev/kmsg
. Dadurch werden sie im Kernel-Protokollpuffer gespeichert, sodass Sie sie mit lesen können dmesg
. Wie Nachrichten, die vom Kernel selbst generiert werden, können diese Nachrichten abhängig von der aktuellen Kernelkonfiguration an die Konsole zurückgesendet werden.