web-dev-qa-db-ja.com

`/ dev / console`は何に使用されますか?

この答え から Linux:/ dev/console、/ dev/tty、および/ dev/tty0の違い

ドキュメント から:

/dev/tty      Current TTY device
/dev/console  System console
/dev/tty0     Current virtual console

昔、/dev/consoleはシステム管理者コンソールでした。 TTYは、サーバーに接続されたユーザーのシリアルデバイスです。現在、/dev/console/dev/tty0は現在の表示を表し、通常は同じです。たとえば、console=ttyS0grub.confに追加することでオーバーライドできます。その後、/dev/tty0はモニターになり、/dev/console/dev/ttyS0になります。

" System console "により、/dev/consoleが仮想コンソールのデバイスファイルであるのと同様に、/dev/tty{1..63}はテキスト物理端末のデバイスファイルのように見えます。

/dev/console/dev/tty0は現在の表示を表し、通常は同じ」ということで、/dev/consoleは仮想コンソールのデバイスファイルにもなるように思えます。 /dev/console/dev/tty0よりも/dev/tty{1..63}に似ています(/dev/tty0は現在アクティブな仮想コンソールであり、/dev/tty{1..63}のどれでもかまいません)。

/dev/consoleとは何ですか?何に使うの?

Linuxカーネルでは、/dev/console/dev/ttyと同じ役割を果たしますか? (/dev/ttyは、プロセスのプロセスセッションの制御端末であり、pts、/dev/ttynnは1〜63、またはそれ以上の場合があります。)

他の返信 言及:

カーネルのドキュメントでは、/dev/consoleが5:1の番号が付けられたキャラクターデバイスとして指定されています。このキャラクターデバイスを開くと、「メイン」コンソールが開きます。これは、コンソールのリストの最後のttyです。

「コンソールのリスト」は ブートオプション のすべてのconsole=を意味しますか?

/dev/console」は、5:1の番号が付いたキャラクターデバイスとして、/dev/consoleが物理的なテキスト端末のデバイスファイル、つまりシステムコンソールであることを意味しますか? (ここでも、上で引用した最初の返信では、/dev/console/dev/tty0と同じにすることができます。これは、物理的なテキスト端末ではなく、仮想コンソールです)

ありがとう。

13
Tim

/dev/consoleは、主にカーネルのコンソールをユーザー空間に公開するために存在します。 デバイスに関するLinuxカーネルのドキュメント は今言う

コンソールデバイス/dev/consoleは、システムメッセージの送信先であり、シングルユーザーモードでのログインを許可するデバイスです。 Linux 2.1.71以降、/dev/consoleはカーネルによって管理されます。以前のバージョンでは、/dev/tty0/dev/tty1などの特定の仮想コンソール、またはシリアルポートプライマリ(tty*ではなくcu*)デバイスへのシンボリックリンクである必要があります、システムの構成に応じて。

/dev/console、メジャー5とマイナー1のデバイスノードは、カーネルがシステム管理者と対話する主要な手段であると見なすものへのアクセスを提供します。これは、システムに接続された物理コンソールにすることができます(仮想コンソールの抽象化が上にあるため、tty0または任意のttyNを使用できます[〜#〜 ] n [〜#〜]は1〜63)、またはシリアルコンソール、ハイパーバイザコンソール、または点字デバイスです。カーネル自体は/dev/consoleを使用しないことに注意してください。デバイスノードはカーネルではなくユーザースペース用です。ただし、/dev/consoleが存在して使用可能であることを確認し、initを標準入力、出力、および/dev/consoleを指すエラーで設定します。

ここで説明するように、/dev/consoleは、メジャーとマイナーが固定されたキャラクターデバイスです。これは、(物理デバイスではなく、カーネルにアクセスする手段のように)独立したデバイスであるため、/dev/tty0またはその他のデバイス。これは、他の仮想コンソールまたは端末デバイスとは少し異なる機能を提供するため、独自のデバイス(5:0)である /dev/ttyの状況 に多少似ています。

「コンソールのリスト」は、確かにconsole=ブートパラメータによって定義されたコンソールのリストです(存在しない場合はデフォルトのコンソール)。このように定義されたコンソールは、/proc/consolesを見るとわかります。 /dev/consoleは確かにアクセスを提供します これらの最後まで

カーネルコマンドラインで複数のconsole =オプションを指定できます。出力はそれらすべてに表示されます。最後のデバイスは、/dev/consoleを開いたときに使用されます。

18
Stephen Kitt

/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/tty0は、現在何かで使用されている/dev/tty{1..63}の1つを表します(おそらくカーネル またはシェルプロセス?)。 /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

あなたが本当にもっと知りたいのなら、 the (M)はモジュールを意味します 。つまりダミーのコンソールデバイスは、ロード可能なカーネルモジュールでは提供されません。これは、初期のカーネルイメージ(別名「builtin」)の一部です。

次に、/sys/class/vtconsoleの各サブディレクトリにあるbindファイルが表示され、アクティブなvtconsoleデバイスがわかります。アクティブなものに0を書き込むと、ダミーに切り替わったように見えます。 (GUI VTは影響を受けていないようですが、テキストVTは機能しなくなります)。ダミーの1を書き込んでも、アクティブにはなりません。どちらの方法でも、実際の方法に切り替えることができます。コードを正しく読んだ場合のトリックは、echo 1 > bindはモジュール(?!)としてビルドされたコンソールドライバーに対してのみ機能することになっているということです。

framebufferコンソールの場合、具体的には、異なるフレームバッファーデバイス(/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を何に使用し、同様にLinuxでconsoleを何に使用しますか?

  1. 技術的には、console/tty0から読み書きできます。たとえば、gettyを実行してtty0にログインできるようにします。しかし、これは簡単なハックとしてのみ役立ちます。これは、Linuxの複数の仮想コンソールを利用できないことを意味します。

  2. systemdは、/ dev/consoleデバイスに関連付けられている属性をsysfsで検索し、基礎となるTTYデバイスを検出します。これにより、systemdが自動的にgettyを生成し、ログインできるようになります。ユーザーがconsole=ttyS0で起動してカーネルコンソールをセットアップしたときのシリアルコンソール。これは便利です。このコンソールを2つの異なる場所で構成する必要がなくなります。繰り返しますが、man systemd-getty-generatorを参照してください。ただし、systemdが実際に/dev/consoleを開くわけではありません。

  3. システムのブートストラップ中は、sysfsがまだマウントされていない場合もあります。しかし、エラーと進行状況のメッセージをできるだけ早く表示できるようにしたいと考えています!したがって、ポイント1)に丸で囲みます。カーネルは、/dev/consoleに接続されたstdin/stdout/stderrでPID 1を開始します。このシンプルなメカニズムを最初からセットアップできるのは非常に便利です。

  4. Linuxコンテナ内では、/dev/consoleのファイルは、キャラクターデバイス番号5:1ではなく、別の何かとして作成される場合があります。代わりに、PTSデバイスファイルとして作成されます。次に、この/dev/consoleファイルを使用してログインすることは理にかなっています。 systemdコンテナー内では、そのようなデバイスにログインできます。 man systemd-getty-generatorを参照してください。

    このメカニズムは、systemd-nspawnコマンドでコンテナーを実行するときに使用されます。 (私は、TTYでsystemd-nspawnを実行したときだけだと思いますが、manページの検索からはわかりません)。

    systemd-nspawnは、コンテナの/dev/consoleをホストからのPTSデバイスのバインドマウントとして作成します。つまり、このPTSデバイスはコンテナ内の/dev/pts/内には表示されません。

    PTSデバイスは、特定のdevptsマウントに対してローカルです。 PTSデバイスは通常のルールの例外であり、デバイスはデバイス番号で識別されます。 PTSデバイスは、デバイス番号とdevptsマウントの組み合わせによって識別されます。

  5. 緊急メッセージをconsole/tty0に書き込んで、ユーザーの現在の仮想コンソールに書き込むことができます。これは、コンソールに出力される緊急のカーネルメッセージ(man dmesgを参照)と同様に、緊急のユーザー空間エラーメッセージに役立ちます。ただし、少なくともシステムの起動が完了したら、これを行うことは一般的ではありません。

    rsyslogには このページの1つの例 があり、カーネルメッセージを/dev/consoleに出力します。カーネルはデフォルトですでにそうしているので、これはLinuxでは無意味です。再度見つけることができない1つの例では、syslogメッセージが多すぎてコンソールをあふれさせて邪魔になりすぎるため、これをカーネル以外のメッセージに使用することはお勧めしません。

    systemd-journaldにも同様に、すべてのログをコンソールに転送するオプションがあります。原則として、これは仮想環境でのデバッグに役立ちます。ただし、デバッグでは通常、代わりに/dev/kmsgに転送します。これにより、カーネルログバッファーに保存され、dmesgで読み取ることができます。カーネル自体によって生成されるメッセージと同様に、これらのメッセージは、現在のカーネル構成によってはコンソールにエコーされる場合があります。

6
sourcejedi