Wofür wird `/dev/console` verwendet?

Lassen Sie mich versuchen, es auf diese Weise zu verstehen. /dev/tty{1..63} und /dev/pts/n sind Gerätedateien, die Geräte selbst darstellen (obwohl sie Emulationen sind), nicht in Bezug auf Prozess oder Kernel. /dev/tty0 stellt den in /dev/tty{1..63} dar die derzeit von etwas verwendet wird (vielleicht Kernel oder Shell-Prozess ?). /dev/tty stellt das steuernde Terminal dar, das derzeit von einer Prozesssitzung verwendet wird. /dev/console stellt das aktuell vom Kernel verwendete Terminal dar?

Was ist die Gerätedatei, die das physische Terminal selbst darstellt, nicht in Bezug auf Kernel oder Prozess?

Die zugrunde liegenden Geräte für /dev/tty{1..63} sind struct con_driver . Um alle möglichen Treiber zu sehen, besuchen Sie 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, die (M) steht für Modul. D.h. das Dummy-Konsolengerät wird nicht von einem ladbaren Kernelmodul bereitgestellt; es ist Teil des anfänglichen Kernel-Images (auch bekannt als "eingebaut").

Zweitens die bind Datei in jedem Unterverzeichnis von /sys/class/vtconsole scheint Ihnen mitzuteilen, welches vtconsole-Gerät aktiv ist. Wenn ich 0 schreibe zum aktiven, scheint es zum Dummy zu wechseln. (GUI-VTs scheinen nicht betroffen zu sein, aber Text-VTs funktionieren nicht mehr). Schreiben von 1 für den Dummy aktiviert man ihn nicht. Beide Methoden funktionieren, um auf die echte zurückzuschalten. Wenn ich den Code richtig gelesen habe, ist der Trick dieser echo 1 > bind soll nur für Konsolentreiber funktionieren, die als Modul gebaut sind (?!).

Für Framebuffer speziell für Konsolen gibt es weitere Informationen zum Binden verschiedener Framebuffer-Geräte (/dev/fb0 ...) zu bestimmten virtuellen Konsolen in https://kernel.org/doc/Documentation/fb/fbcon.txt . Dies beinhaltet eine Kernel-Option fbcon:map= oder ein Befehl namens con2fbmap .

Natürlich können die Details mit verschiedenen Kernel-Versionen, Architekturen, Firmwares, Geräten, Treibern usw. variieren. Ich musste nie wirklich eine der oben genannten Schnittstellen verwenden. Der Kernel lässt einfach i915 zu / inteldrmfb / wie auch immer Sie es nennen möchten, übernehmen Sie, wenn es geladen wird, und ersetzen Sie z. vgacon .

Es sieht so aus, als hätte mein EFI-Rechner nie vgacon . Es wird also erstens eine Dummy-Konsole verwendet und zweitens nach 1,2 Sekunden auf fbcon umgeschaltet , die auf efifb ausgeführt wird . Aber bisher musste ich mich nicht um die Details kümmern; 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. "Was ist /dev/console verwendet für?"

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 an ein anderes Gerät gebunden sein.

In diesem Fall schreibt das Schreiben nach /dev/console also nach /dev/tty0. Und wiederum ist das Schreiben auf /dev/tty0 gleichbedeutend mit dem Schreiben auf das gerade aktive /dev/ttyN-Gerät.

Aber das wirft eine interessante Frage auf. Zugriff auf tty0 greift auf verschiedene virtuelle Konsolen zu, je nachdem, welche gerade aktiv ist. Was verwenden die Leute eigentlich tty0 for, und ähnlich was ist console verwendet für unter Linux?

1. Technisch gesehen können Sie ab console lesen und schreiben / tty0 , zum Beispiel das Ausführen eines getty um die Anmeldung auf tty0 zu ermöglichen . Dies ist jedoch nur als schneller Hack nützlich. Weil es bedeutet, dass Sie die zahlreichen virtuellen Konsolen von Linux nicht nutzen können.

2. systemd sucht in sysfs für ein Attribut, das dem Gerät /dev/console zugeordnet ist, um das zugrunde liegende TTY-Gerät zu erkennen. Dies erlaubt systemd um automatisch einen getty zu spawnen und erlauben Sie sich z.B. eine serielle Konsole, wenn der Benutzer eine Kernel-Konsole durch Booten mit console=ttyS0 einrichtet . Das ist bequem; es vermeidet die Notwendigkeit, diese Konsole an zwei verschiedenen Stellen zu konfigurieren. Siehe noch einmal man systemd-getty-generator . Jedoch systemd öffnet nicht wirklich /dev/console dafür.

3. Während des System-Bootstrap haben Sie möglicherweise noch nicht einmal sysfs gemountet. Aber Sie möchten Fehler- und Fortschrittsmeldungen so schnell wie möglich anzeigen können! Also kreisen wir um Punkt 1). Der Kernel startet PID 1 mit stdin/stdout/stderr verbunden mit /dev/console . Es ist sehr schön, diesen einfachen Mechanismus von Anfang an eingerichtet zu haben.

4. In einem Linux-Container die Datei unter /dev/console kann als etwas anderes erstellt werden - nicht das Zeichen Gerätenummer 5:1 . Stattdessen kann es als PTS-Gerätedatei erstellt werden. Dann wäre es sinnvoll, sich über diesen /dev/console anzumelden Datei. systemd in einem Container ermöglicht die Anmeldung auf einem solchen Gerät; siehe man systemd-getty-generator .

   Dieser Mechanismus wird verwendet, wenn Sie einen Container mit dem systemd-nspawn ausführen Befehl. (Ich denke nur, wenn Sie systemd-nspawn ausführen auf einem TTY, obwohl ich es anhand der Manpage nicht erkennen kann).

   systemd-nspawn erstellt den /dev/console des Containers als Bind-Mount eines PTS-Geräts vom Host. Das bedeutet, dass dieses PTS-Gerät in /dev/pts/ nicht sichtbar ist im Behälter.

   PTS-Geräte sind lokal für einen bestimmten devpts montieren. 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 ihres devpts identifiziert montieren.

5. Sie können dringende Nachrichten an console schreiben / tty0 , um in die aktuelle virtuelle Konsole des Benutzers zu schreiben. Dies könnte für dringende Userspace-Fehlermeldungen nützlich sein, ähnlich dringenden Kernel-Meldungen, die auf der Konsole ausgegeben werden (siehe man dmesg ). Es ist jedoch nicht üblich, dies zu tun, zumindest nachdem das System hochgefahren ist.

   rsyslog hat auf dieser Seite ein Beispiel, das Kernel-Meldungen an /dev/console ausgibt; Dies ist unter Linux sinnlos, da der Kernel dies bereits standardmäßig tut. Ein Beispiel, das ich nicht wiederfinden kann, besagt, dass es keine gute Idee ist, dies für Nicht-Kernel-Meldungen zu verwenden, da es einfach zu viele Syslog-Meldungen gibt, Sie Ihre Konsole überfluten und es zu sehr im Weg steht.

   systemd-journald hat ebenfalls Optionen, um alle Protokolle an die Konsole weiterzuleiten. Im Prinzip kann dies für das Debuggen in einer virtuellen Umgebung nützlich sein. Zum Debuggen leiten wir jedoch normalerweise an /dev/kmsg weiter stattdessen. Dadurch werden sie im Kernel-Protokollpuffer gespeichert, sodass Sie sie mit dmesg lesen können . Wie Nachrichten, die vom Kernel selbst generiert werden, können diese Nachrichten abhängig von der aktuellen Kernel-Konfiguration an die Konsole gesendet werden.