"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/consoleverwendet?"
Unter Linux werden /dev/consoleMeldungen 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/consolewar 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/nsind Gerätedateien, die Geräte selbst darstellen (obwohl es sich um Emulationen handelt), nicht in Bezug auf den Prozess oder den Kernel. /dev/tty0stellt den dar, in /dev/tty{1..63}dem gerade etwas verwendet wird (vielleicht Kerneloder Shell-Prozess?). /dev/ttyStellt das steuernde Terminal dar, das derzeit von einer Prozesssitzung verwendet wird. /dev/consoleStellt 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 bindDatei in jedem Unterverzeichnis von /sys/class/vtconsolean, welches vtconsole-Gerät aktiv ist. Wenn ich 0auf das aktive schreibe , scheint es auf das Dummy umzuschalten. (GUI-VTs scheinen nicht betroffen zu sein, Text-VTs funktionieren jedoch nicht mehr). Schreiben 1fü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 > bindnur 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/consoleverwendet?"
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 tty0werden verschiedene virtuelle Konsolen aufgerufen, je nachdem, welche gerade aktiv sind. Wofür verwenden die Leute eigentlich tty0und was wird consoleauf 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.
systemdsucht sysfsnach 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 gettyund 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 systemdsich aber eigentlich nicht /dev/consoledafü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/consoleunter 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/consoleDatei anzumelden . systemdIn 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-nspawnBefehl ausführen . (Ich denke nur, wenn Sie systemd-nspawnauf einem TTY laufen , obwohl ich von der Suche in der Manpage nicht unterscheiden kann).
systemd-nspawnErstellt den Container /dev/consoleals 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 devptsMount. 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 devptsHalterung identifiziert .
Sie können dringende Nachrichten an console/ tty0schreiben, 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.