/sysおよび/devディレクトリに埋め込まれる内容

Question 1

マウントされたファイルシステムはファイルシステム/sysです。いわゆる例ですsysfssysfs仮想ファイルシステムまたは擬似ファイルシステム。これらのファイルシステムは、実際に物理的に保存されたファイルを表していないため、「仮想」と呼ばれます。合成ファイルではなくデータ構造のファイル形式のビュー。

したがって、sysfsカーネル内部にファイルのようなビューを結合したファイルシステムである。

各ドライバ/モジュールの使命は、カーネルオブジェクトモデルに自分とそのデータ構造を登録して、カーネルの残りの部分がこれらのデータ構造を「理解」できるようにすることです。しかし、このオブジェクトモデルをsysfs。sysfsデバイス固有の情報についてのみ、モジュールはsysfsそれをどのように表示するかを知らなければなりません。

仮想ファイルシステムの最もよく知られていて最も古い例は、通常1984年にUnix V8にマウントされているprocfsファイルシステムです/proc。procfsそれ以来、1991年にSVR4に移植され、4.4BSDにコピーされたPlan 9のより包括的な実装に触発されました。興味深いことに、FreeBSDとOpenBSDはどちらもこの機能を段階的に廃止しましたが、procfsmacOSではこの機能を使用したことはありません。

Linuxはprocfs1992年にAを受け取りました。従来、Linuxでは、procfsプロセス関連データを扱うのではなく、さまざまなデータをユーザー空間にエクスポートするために使用されていました。しかし、長い間このデータがどのように公開されるかを管理する標準がなかったので、あらゆる種類のさまざまなスタイルを見つけることができました。一部のデータは人間が読みやすいが、理解しにくい方法で公開されている。機械が読みやすいように、解析やその他の最適化のためのスクリプトを使用してください。一部の複雑なデータは1つの大きなファイルとして表示され、他のデータはコンポーネントごとに1つのファイルがあるディレクトリとして表示されます。

sysfsこれらの混乱をクリーンアップするために導入されたこの機能には、データ表現方法に関する厳格な規則があります。

については/dev別の話があります。伝統的に、/devこれはルートファイルシステムの一般的なディレクトリです。システム管理者は、このmknodユーティリティを使用してデバイスノードを作成する責任があります。時間が経つにつれて、Unixディストリビューションはシステム管理者が最も重要なデバイスノードを作成するために実行できる事前に作成されたスクリプトを提供し始めます。です。システム管理者はこれを手動で作成する必要はありません。

ホットプラグ対応デバイスのサポートが引き続き増加し（特にUSBとFirewireの導入により）、Linuxが経験豊富な「システム管理者」がしばしば存在しない市場（消費者デスクトップなど）にますます移動するにつれて、すべてのデバイスのすべてのデバイスノードは、デバイスを接続または切断するたびにシステム管理者が手動で作成および削除するため、実行可能なオプションではありません。

これにより、devfsカーネルが検索した各デバイスのデバイスノードを自動的に含む仮想ファイルシステムが作成されます。しばらくの間devfs、デバイスを検出し、スクリプトを実行してデバイスノードを生成する方法でプラグアンドプレイを処理するディストリビューションアプローチが共存しました。

品質と実装についていくつかの批判がありましたdevfs。特に、カーネル内で内部的に処理するために実際にデバイスノードを作成して削除する必要がないという批判がありましたdevfs。削除するカーネルのものは必ずしも存在する必要はありません。

Linuxカーネル開発の原則の1つは、「メカニズムはカーネルにあり、ポリシーはユーザースペースになければなりません」ですが、devfsこれは次の理由で違反します。意思決定カーネルで「このデバイスの名前を何に指定する必要がありますか？」

その結果、udev開発されました。udevいくつかのコンポーネントで構成され、最も重要なのはデーモンsysfs（およびその他のリソース）です。udev イベント）システムで利用可能なデバイスの変更を特定し、カスタマイズ可能なセットを使用します。ルール対応するデバイスノードを作成して削除します。udev必要な情報はすでにsysfs他の場所で利用可能で、通常の/devファイルシステムになる可能性があるため、カーネルの特別なサポートは必要ありません。

今日、ほとんどのLinuxディストリビューションではこれを使用していますが、udev（BusyBoxのフォーク）や（軽量リソースが制限されたシステム用に設計されたBusyBoxベースの最小代替）など、開発された代替もudev使用しています。これは、カーネルからユーザー空間に機能を移動することによる大きな利点です。通常、カーネルには機能のインスタンスが1つしかない場合がありますが、ユーザースペースでは競合の実装が簡単です。簡単に交換できます。一般に、競争はより良い品質につながります。eudevudevmdevudev

通常、一時ファイルシステムは次の場合にudev使用されます/dev。これにより、システムのクラッシュや再起動後に古いデバイスノードをクリーンアップすることを心配する必要がなくなります。常に空のファイルシステムで始まるため、udev実際に存在するデバイスのデバイスノードのみが再作成されました。

ルートファイルシステムを使用し、起動スクリプトのどこかからコンテンツを削除するか/dev（起動には少なくともいくつかのワーカーデバイスノードが必要なため、トリッキーですが/dev）使用できますtmpfs（メモリにのみ存在します）。を使用しても同じ問題が発生します。

udevこれは、動作するために少なくとも一部のデバイスノードが必要ですudevが、udevデバイスノードを作成するデバイスノードである場合は、作業を開始する方法に関するブートストラップの問題を解決するためにdevtmpfs開発されました。

これで、ある意味ではdevtmpfs非常に似ているので、なぜこれが許可されていないのかをdevfs諮問することができます。 2つの重要な違いがあります。ヒントはすでに ""という名前にあります。構築：今問題が解決したので、RAMでファイルを表現する方法を再考したいのはなぜですか？（これはすでに存在する多くの機能を複製するというもう一つの批判です。）devtmpfsdevfsdevtmpfsdevtmpfstmpfstmpfsdevfstmpfs

もう1つの違いは、devtmpfsデバイスノードを作成する方法が非常に簡単で、より複雑なことはここに任せることですudev。たとえば、devtmpfsデバイスに複雑な命名規則を実装しようとせずに、ユーザーになることができるudev非常に単純な名前のみを使用します。定義済みルールセットは、カスタム名からカーネル定義名へのシンボリックリンクを生成します。

したがって、最新のLinuxシステムでは、通常、いくつかのベアボーンデバイスノードを作成するdevtmpfsインストールがあります。ここでインストールすると、カーネルの内部をファイルとして公開し、udevイベントを介してカーネルからデータを受け取り、リンクを作成するユーザースペースで実行されます。カスタマイズされた規則に従ってこれらのベアボーンデバイスに適用されます。/devsysfs/sysudevsysfs

一つあるたくさんさらに、これは10,000kmの概要です。

Answer