UNIXデバイスファイルが静的であると言う人はどういう意味ですか?

UNIXデバイスファイルが静的であると言う人はどういう意味ですか?

私は読んでいたウデブ。 「概要」セクションでは、Wikipediaは、「/ devディレクトリのデバイスノードが静的ファイルセットである既存のUnixシステムとは異なり、Linux udevデバイスマネージャは、デバイスに実際に存在するノードのみを動的に提供します。システム」。

「静的ファイルセット」とはどういう意味ですか?これは常にファイルがありますが、必ずしも/dev実際のデバイスを指しているわけではありませんか?

答え1

私はあなたがこの段落に言及していると仮定します。

/ devディレクトリのデバイスノードが静的ファイルセットである既存のUnixシステムとは異なり、Linux udevデバイスマネージャは、システムに実際に存在するデバイスに対してのみ動的にノードを提供します。 devfsはかつて同様の機能を提供しましたが、Greg Kroah-Hartmanはいくつかの理由を引用しています。サムdevfsと比較して実装を好みます。

/dev最初の文では、デバイスが静的に作成され、再起動後も持続する他のUnixシステムを参照します。以前のバージョンのLinux(2.4カーネルなど)はこのように動作しましたが、最新バージョンではこれ以上機能しません。他のUnixには通常、インストール中に共通のデバイスファイルセットが含まれているため、追加のファイルを手動で作成する必要はほとんどありません。

2.4では、このmknodコマンドを使用して必要なデバイスファイルを手動で生成できます。たとえば、

$ mknod ./dev/random b 12 5

メモ:これは、/dev/randomファイル記述子をメジャー番号12とマイナー番号5のブロックデバイスとして生成することを意味します。

/ devの下のデバイスファイル

OPはディレクトリの全体的な機能について次の質問をしました/dev。彼の質問は次のとおりです。

再起動後にデバイスファイルを保存する技術的な方法に関する詳細を追加できますか?ディスクに物理的にどのように保存されますか?特別なファイルシステムサポートが必要ですか?

この問題を調査しながら、次から始めるべきだと思いました。最初からLinuxプロジェクト/dev最新バージョンのLinuxカーネルで管理する方法の基本概念を学びます。以前は(カーネルバージョン2.4以前を考えてみてください)、/devディレクトリは実際にはHDDのスペースを占める静的ファイルのセットでしたが、Linuxの出現によりもはやそうではudevありませsysfsんでした。

従来、これらの特殊ファイルは、インストール中にコマンドを使用して展開によって生成されますmknod。近年、Linuxシステムは実行時にudevこれらのファイルを管理し始めました/dev。たとえば、udevデバイスが検出されるとノードが作成され、デバイスが削除されると削除されます(実行時にホットプラグデバイスを含む)。これにより、/devディレクトリ(ほとんど)には、存在できるデバイスではなく、現在のシステムに実際に存在するデバイスのエントリのみが含まれます。

心配しないでください/dev。ディレクトリは再起動udevと再起動によって完全に管理されますsysfs

追加リソースudevsysfs

引用する

答え2

「デバイスファイル」は特殊なタイプのファイルです(ディレクトリ、シンボリックリンク、名前付きパイプ、およびUnixドメインソケットが特殊なタイプのファイルであるのとほぼ同じ方法です)。ユーザーデータを直接保存せずに、代わりにプライマリおよびセカンダリデバイス番号とデバイスタイプ(文字またはブロック)を保存します。 Unixシリーズシステム用に設計されたファイルシステムは、ストレージデバイスファイルをサポートします。

アプリケーションまたはインストールコマンドを介して「デバイスファイル」にアクセスすると、ファイルシステムからプライマリおよびセカンダリデバイス番号とデバイスタイプが検索されます。この番号に基づいて、カーネルはドライバを選択して開きます。

伝統的に、デバイスファイルはルートファイルシステムの/ devというディレクトリにのみ存在し、通常は設定ファイルを読み込み、デバイスノードを作成する「MAKEDEV」というツールによって生成されます。これは静的設定と呼ばれ、ほぼすべてのUNIXシリーズオペレーティングシステム(Linuxを含む)で長年使用されてきました。このアプローチにはいくつかの欠点がある。

  • 現在のシステムにそのハードウェアが存在しない場合でも、デバイスファイルは存在します。どのハードウェアが存在するのか、存在しないのかを言うのは難しいです。
  • カーネルのアップグレードによって新しいデバイスタイプが導入される場合、管理者はそのタイプのデバイスノードを手動で作成する必要があります。
  • メジャー番号とマイナー番号の供給は限られており、各デバイスノードにペアを静的に割り当てることは(パーティション化のために1つの物理デバイスが複数のデバイスノードを持つ可能性があることに注意してください)、拡張できません。

この問題を解決するためのLinuxの最初の試みはdevfsでした(他のUnix系オペレーティングシステムにもdevfsというファイルシステムがありましたが、詳細はわかりません)。これはカーネルがデバイスノードを提供する仮想ファイルシステムです。実際、比較的まだ生まれていない状態であり、良いか嫌いでも、独自の非標準デバイス命名スキームを導入し、static / devに比べて大きな利点を提供していません。

後でudevが登場しました。これは異なるモデルを使用します。 tmpfsは/ devにマウントされ、ユーザースペースデーモンはカーネルの通知に基づいてその中のデバイスノードを管理します。https://lwn.net/Articles/65197/

最近、devtmpfsということがわかりました。これは妥協のようです。カーネルはデフォルトのデバイスノードセットを作成しますが、より複雑な機能が必要な場合は、ユーザースペースが代用できます。

答え3

Altos 386(i386 / SCO SysV Unix)システムでカーネルをアップグレード(または再インストール)するときに作成する必要がある静的デバイスの例には、SCSI HP Dat Tapeデバイスをサポートするための余分な/ dev / mtエントリがあります。メジャー番号はSCSIバス上のテープドライバに使用され、マイナー番号はSCSIデバイス番号と機能(オリジナル、巻き戻し、巻き戻しを除く)に使用されます。各バスには、HD拡張ファイルシステムを搭載した複数のハイブリッドテープデバイスをサポートできる2つのSCSIバスがあります。

devは単にMAKEDDEVで作成されたルートファイルシステムのエントリです。実用的な目的のために、SCSIデバイス5の巻き戻しデバイスを/ dev / st(内蔵DC300デバイスと区別するためにSCSIテープ)に接続できるように、より使いやすい名前に接続できます。

後でSlackware Linuxの使用を開始したときに同じことを行う必要があり、3Com 3C509bコンボイーサネットカードを正しく使用するには、.99bカーネルを手動でパッチする必要がありました。カテゴリ5、BNC、AUIコネクタがあり、ゲームの実行時に正しいインターフェイスを取得できます。

関連情報