sysfsとdevtmpfs

カーネルは sysfs を使用して、udev で使用できるようにデバイスノードをユーザ空間にエクスポートします。

いいえ。 Sysfs にはデバイスノードは含まれません。 Sysfsには、主にデバイス情報を提供するファイルと、プロセスがデバイスの動作を制御できるファイルがいくつか含まれています。ただし、ほとんどのデバイスは sysfs が提供する機能では使用できません。

ハードドライブを例に挙げましょう。下のどこかにディレクトリがあり/sys/devices、パスはコンピュータに接続されている方法によって異なります（たとえば、/sys/devices/pci0000:00/…コンピュータのプライマリPCIバスに接続されているコントローラに接続されているディスクなど）。このディレクトリでは、サイズ、取り外し可能性、電源状態などのさまざまな情報を見つけることができます。パーティション用のサブディレクトリもあります。ただし、ディスクの内容へのアクセスを提供する内容はありません。の他の場所には、そのディスクに対応するディレクトリ（in、inなど）/sysへのシンボリックリンクがあります。ただし、まだディスクの内容にアクセスできません。/sys/block/sys/class/block

の/devディスクエントリは特殊ファイルです。ブロックデバイス。このファイルを使用すると、プロセスはディスクの内容を読み書きできます。 （ディスクの場合、通常これは発生しません。代わりに、ディスクまたはパーティションの内容がマウントされ、カーネルはデバイスにアクセスしますが、プロセスはアクセスしません。）

デバイスファイルは、以下を介してコンテンツを読み書きする以外の一部の操作を許可します。I/W制御。 sysfs が提供するすべての情報および制御インタフェースは、デバイスファイルの ioctl を通じて利用できます。しかし、これは次のようなさまざまな理由で不便です。

• 権限は別のファイルで/sys詳細に設定できます。デバイスごとにファイルが1つしかない場合は、完全でない限りは/dev専務です。
• アプリケーションは個々のファイルを簡単に読み書きできます。catまたはを使用してくださいecho。 ioctlの使用ははるかに難しいです。シェルインターフェイスはなく、通常、他の高級言語にはインターフェイスがありません。
• ioctlを使用すると、コマンドは名前ではなく数字でエンコードされ、引数の形式はバイナリレベルで定義する必要があります。名前と単純なテキスト形式を使用すると、ソフトウェアの作成が簡単になります。

別の方向に見ると、sysfsのファイルを介してデバイスのコンテンツにアクセスできます。ただし、これにはカーネルで追加の作業が必要です。 sysfsは主に小さなファイルとシンボリックリンクを提供するように設計されており、ioctl既存のアプリケーションが期待するサポートはありません。既存のデバイスタイプをサポートするようにsysfsを拡張することに大きな利点がないと思われるので、デバイスファイルは存在し続けます。

Sysfsはカーネルによって自動的に入力され、実際に利用可能なデバイスをリアルタイムで反映します。 sysfsでは、ファイルの意味は、ファイルを提供するドライバが選択するパスから来ます。/dev別の方法で動作します。ファイルの意味は、デバイスファイルの種類（ブロックまたは文字）と、プライマリ番号とセカンダリ番号（リストされており、デバイスls -lのファイルサイズではありません）から来ます。伝統的に、/devこれはシステムのインストール中に生成されたデバイスファイルを使用して静的でしたが、デバイスがホットプラグ可能な場合は適用性が低く、接続されている/devデバイスの動的特性をリアルタイムで反映する必要があります。

Linuxは動的に多くの反復を経ました/dev。 Linux 2.4ではファイルシステムの開発ここでカーネルは、接続されたデバイスを反映するアイテムを自動的に生成します。しかしそれはあまり良くない、デバイスの命名、および権限ポリシーをカーネルにハードコーディングしたため、userlandプログラムに置き換えられました。ウデブ管理ポリシーと/dev単純なtmpfsファイルシステム（カーネルに特別な意味を持たないインメモリファイルシステム）。その後、devfs 部分が再び表示されます。開発者ファイルシステム、これはカーネルによって利用可能なデバイスのエントリが自動的に作成されますが、udevはその上に必要なすべての管理を実行するtmpfsのインスタンスです。