“什么/dev/console？” 在上一个答案中被回答。当您知道其他两个问题的答案时，也许答案会更清楚。
Q1。“代表物理终端本身的设备文件是什么？”
没有这样的设备文件。
Q2。“是/dev/console用来干什么的？”
在Linux上，/dev/console用于在启动（和关闭）期间显示消息。正如斯蒂芬·基特（Stephen Kitt）的回答所指出的，它也用于“单用户模式”。使用它没有其他意义。
Unix的“美好时光” /dev/console是专用的物理设备。但这在Linux中并非如此。
相关证据
1.“代表物理终端本身的设备文件是什么？”
让我尝试理解这种方式。/dev/tty{1..63}并且/dev/pts/n是代表设备本身的设备文件（尽管它们是仿真的），与进程或内核无关。/dev/tty0代表/dev/tty{1..63}当前某物正在使用的那个（也许是内核或壳工艺？）。/dev/tty代表过程会话当前使用的控制终端。/dev/console代表内核当前使用的终端？
代表物理终端本身的设备文件是什么，与内核或进程无关？
的基础设备/dev/tty{1..63}是struct con_driver。要查看所有可能的驱动程序，请查看https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console
这些底层设备没有设备文件！
只有最小的用户空间界面可以管理它们。
$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device
==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device
如果您真的想了解更多信息，请参阅(M)module。即虚拟控制台设备不是由可加载的内核模块提供的；它是初始内核映像（也称为“内置”）的一部分。
其次，出现bind在每个子目录中的文件/sys/class/vtconsole告诉您哪个vtconsole设备处于活动状态。如果我写0一个活动的，似乎切换到虚拟的。（GUI VT似乎不受影响，但是文本VT停止工作）。1为假人写不会激活它。两种方法都可以切换回真实方法。如果我正确地阅读了代码，则诀窍是echo 1 > bind只能用于作为模块构建的控制台驱动程序（？！）。
特别是对于帧缓冲控制台，https： //kernel.org/doc/Documentation/fb/fbcon.txt中提供了有关将不同的帧缓冲设备（/dev/fb0...）绑定到特定虚拟控制台的更多信息。这涉及内核选项或称为的命令。fbcon:map=con2fbmap
当然，详细信息可能会随内核版本，体系结构，固件，设备，驱动程序等的不同而有所不同。我从未真正使用过上面的任何接口。内核仅在加载时让i915// inteldrmfb您想要调用的任何内容接管，替换为例如vgacon。
看来我的EFI机器从未有过vgacon。因此，首先使用虚拟控制台，然后在1.2秒后切换到fbcon，在之上运行efifb。但是到目前为止，我还不需要关心细节。它只是工作。
$ 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.“ /dev/console用于什么？”
您可以将/ dev / console用作TTY设备。例如，对其进行写入将写入特定的基础设备，该设备还将具有其自己的字符设备编号。
/ dev / console通常绑定到/ dev / tty0，但有时可能绑定到其他设备。
因此，在这种情况下，写入/ dev / console将写入/ dev / tty0。反过来，写入/ dev / tty0等效于写入当前处于活动状态的任何/ dev / ttyN设备。
但这提出了一个有趣的问题。访问tty0将访问不同的虚拟控制台，具体取决于当前处于活动状态的虚拟控制台。人们实际使用tty0什么，并且类似地console在Linux上使用什么？
从技术上讲，您可以从console/ tty0进行读写，例如运行a getty来允许登录tty0。但这仅是一种快速的技巧。因为这意味着您无法利用Linux的多个虚拟控制台。
systemd查找sysfs与/ dev / console设备关联的属性，以检测基础的TTY设备。当用户使用引导设置内核控制台时，这允许systemd自动生成a getty并允许在串行控制台上登录console=ttyS0。这很方便；它避免了在两个不同位置配置此控制台的需要。再次参见man systemd-getty-generator。但是，systemd实际上并没有/dev/console为此打开。
在系统引导过程中，您甚至可能尚未安装sysfs。但是您希望能够尽快显示错误和进度消息！因此，我们绕过点1）。内核通过将stdin / stdout / stderr连接到来启动PID 1 /dev/console。从一开始就设置这种简单的机制非常好。
在Linux容器内，文件at /dev/console可能会创建为不同的名称，而不是字符设备number 5:1。而是可以将其创建为PTS设备文件。然后，通过该/dev/console文件登录将很有意义。 systemd容器内将允许登录此类设备；见man systemd-getty-generator。
使用systemd-nspawn命令运行容器时，将使用此机制。（我认为仅当您systemd-nspawn在TTY上运行时，尽管我无法从搜索手册页中得知）。
systemd-nspawn/dev/console从主机创建容器作为PTS设备的绑定安装。这意味着该PTS设备/dev/pts/在容器内部不可见。
PTS设备位于特定devpts安装的本地。PTS设备是正常规则的例外，该规则由设备的设备号标识。PTS设备通过其设备编号和devpts安装方式的组合来标识。
您可以将紧急消息写入console/ tty0，以写入用户当前的虚拟控制台。这对于紧急用户空间错误消息很有用，类似于打印到控制台的紧急内核消息（请参阅参考资料man dmesg）。但是，至少在系统完成引导之后才执行此操作。
rsyslog 在此页面上有一个示例，该示例将内核消息打印到/dev/console；这在Linux上毫无意义，因为默认情况下内核已经这样做了。一个我再也找不到的示例说，将其用于非内核消息不是一个好主意，因为有太多的syslog消息，您充斥了控制台，并且妨碍了太多。
systemd-journald同样具有将所有日志转发到控制台的选项。原则上，这对于在虚拟环境中进行调试可能很有用。虽然，对于调试，我们通常/dev/kmsg转而使用。这会将它们保存在内核日志缓冲区中，因此您可以使用读取它们dmesg。类似于内核本身生成的消息，这些消息可能会根据当前内核配置回显到控制台。