「なに/dev/console？」前の回答で回答されています。おそらく、他の2つの質問に対する答えがわかっていれば、その答えはより明確になります。
Q1。「物理端末自体を表すデバイスファイルは何ですか？」
そのようなデバイスファイルはありません。
Q2。「何に/dev/console使うの？」
Linuxでは、/dev/console起動中（およびシャットダウン中）にメッセージを表示するために使用されます。Stephen Kittの答えで指摘されているように、「シングルユーザーモード」にも使用されます。それを使用する意味がある他の多くはありません。
Unixの「古き良き時代」/dev/consoleは、専用の物理デバイスでした。しかし、これはLinuxには当てはまりません。
関連する証拠
1.「物理端末自体を表すデバイスファイルは何ですか？」
この方法を理解してみましょう。/dev/tty{1..63}また/dev/pts/n、プロセスまたはカーネルに関連するのではなく、デバイス自体を表すデバイスファイルです（エミュレーションですが）。/dev/tty0reprsentsに1 /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
もっと知りたい場合は、module の(M)略です。つまり、ダミーコンソールデバイスはロード可能なカーネルモジュールによって提供されません。これは、初期カーネルイメージ（別名「ビルトイン」）の一部です。
次に、のbind各サブディレクトリにあるファイルが/sys/class/vtconsole表示され、アクティブなvtconsoleデバイスがわかります。0アクティブなものに書き込むと、ダミーのものに切り替わるように見えます。（GUI VTは影響を受けていないようですが、テキストVTは動作を停止します）。書き込み1ダミー1、それを活性化させないために。どちらの方法でも、実際の方法に戻ります。コードを正しく読んだ場合の秘theはecho 1 > bind、モジュール（？！）としてビルドされたコンソールドライバーでのみ機能することです。
具体的には、フレームバッファーコンソールについては/dev/fb0、https: //kernel.org/doc/Documentation/fb/fbcon.txtに、異なるフレームバッファーデバイス（...）を特定の仮想コンソールにバインドすることに関する詳細情報があります。これには、カーネルオプション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たとえば、を実行しgettyてログインできるようにしtty0ます。しかし、これは簡単なハックとしてのみ有用です。それは、Linuxの複数の仮想コンソールを利用できないことを意味するためです。
systemdsysfs基礎となるTTYデバイスを検出するために、/ dev / consoleデバイスに関連付けられた属性を探します。これが可能にsystemd自動的に産卵Aにgetty、ユーザーがでブートしてカーネルコンソールを設定する例えば、A、シリアルコンソール、上のログインを許可しますconsole=ttyS0。これは便利です。このコンソールを2つの異なる場所で構成する必要がなくなります。繰り返しますが、を参照してくださいman systemd-getty-generator。ただし、systemd実際に/dev/consoleはこのために開きません。
システムのブートストラップ中に、sysfsがまだマウントされていない場合もあります。ただし、できるだけ早くエラーメッセージと進行メッセージを表示できるようにする必要があります。したがって、ポイント1）に移動します。カーネルは、に接続されたstdin / stdout / stderrでPID 1を開始し/dev/consoleます。この単純なメカニズムを最初から設定しておくと非常に便利です。
Linuxコンテナー内では、ファイル/dev/consoleは、キャラクターデバイス番号ではなく、異なるものとして作成される場合があります5:1。代わりに、PTSデバイスファイルとして作成される場合があります。次に、この/dev/consoleファイルを介してログインするのが理にかなっています。 systemdコンテナ内では、そのようなデバイスにログインできます。を参照してくださいman systemd-getty-generator。
このメカニズムは、systemd-nspawnコマンドでコンテナを実行するときに使用されます。（私はあなたが実行したときだけだと思うsystemd-nspawn私はmanページを検索から言うことができないものの、TTY上）。
systemd-nspawn/dev/consoleホストからPTSデバイスのバインドマウントとしてコンテナを作成します。これは、このPTSデバイスが/dev/pts/コンテナ内に表示されないことを意味します。
PTSデバイスは、特定のdevptsマウントに対してローカルです。PTSデバイスは、デバイスがデバイス番号で識別されるという通常の規則の例外です。PTSデバイスは、デバイス番号とdevptsマウントの組み合わせによって識別されます。
緊急メッセージをconsole/ tty0に書き込んで、ユーザーの現在の仮想コンソールに書き込むことができます。これは、コンソールに出力される緊急カーネルメッセージに似た、緊急のユーザー空間エラーメッセージに役立ちます（を参照man dmesg）。ただし、少なくともシステムの起動が完了したら、これを行うことは一般的ではありません。
rsyslogのこのページには、カーネルメッセージを出力する1つの例があります/dev/console。カーネルはデフォルトで既にそうしているので、これはLinuxでは無意味です。私が再び見つけられない1つの例は、あまりにも多くのsyslogメッセージがあり、コンソールをあふれさせ、それが邪魔になるため、これを非カーネルメッセージに使用することは良い考えではないと言います。
systemd-journaldにも同様に、すべてのログをコンソールに転送するオプションがあります。原則として、これは仮想環境でのデバッグに役立ちます。ただし、デバッグのために、通常は/dev/kmsg代わりに転送します。これにより、カーネルログバッファーに保存されるため、で読み取ることができますdmesg。カーネル自体によって生成されるメッセージと同様に、これらのメッセージは現在のカーネル構成に応じてコンソールにエコーされる場合があります。