sysfsとdevtmpfs
lrich Dangelが説明します devtmpfsとudevの違いは非常によくわかります。
Sysfsはどうですか？
カーネルがsysfsを使用して、udevが使用するデバイスノードをユーザースペースにエクスポートすることを理解しています。では、devtmpfsとsysfsは同じですか？はいの場合、なぜ彼らは異なる名前を使用するのですか？いいえの場合、sysfsとdevtmpfsの本当の違いは何ですか？
カーネルはsysfsを使用して、udevが使用するデバイスノードをユーザースペースにエクスポートします
いいえ。Sysfsにはデバイスノードは含まれていません。 Sysfsには主に、デバイスに関する情報を提供するファイルと、プロセスがデバイスの動作を制御できるようにするファイルが含まれています。しかし、ほとんどの場合、sysfsが提供するものを介してデバイスを使用することはできません。
ハードディスクを例にとってみましょう。 /sys/devicesの下のどこかに、コンピューターへの接続方法に応じたパスを持つディレクトリがあります（たとえば、コンピューターのプライマリPCIバスに接続されているコントローラーに接続されているディスクの場合は/sys/devices/pci0000:00/…）。そのディレクトリには、サイズ、リムーバブルかどうか、電源状態など、さまざまな情報があります。パーティションのサブディレクトリもあります。しかし、ディスクのコンテンツへのアクセスを提供するものは何もありません。 /sysの他の場所には、そのディスクに対応するディレクトリへのシンボリックリンクがあります。/sys/block、/sys/class/blockなどです。ただし、ディスクのコンテンツにアクセスするためのリンクはまだありません。
/devでは、ディスクのエントリは特別なファイル— ブロックデバイス です。このファイルにより、プロセスはディスクの内容を読み書きできます。 （ただし、通常は発生しないディスクの場合、代わりにディスクのコンテンツ（またはパーティションのコンテンツ）がマウントされるため、カーネルはデバイスにアクセスしますが、プロセスはアクセスしません。）
デバイスファイルを使用すると、コンテンツの読み取りと書き込み以外の一部の操作を ioctl で実行できます。 sysfsがデバイスファイルのioctlを介して提供するすべての情報と制御インターフェイスを提供することが可能です。ただし、これはいくつかの理由であまり便利ではありません。
/sysに個別のファイルを使用すると、権限をきめ細かく設定できます。/devのデバイスごとに1つのファイルがある場合、それはすべてかゼロかです。- 個別のファイルは、アプリケーションで簡単に読み書きできます。
catまたはechoを使用できます。 ioctlを使用すると、はるかに困難になります。シェルインターフェイスがなく、他の高級言語のインターフェイスがないことがよくあります。 - Ioctlを使用する場合、コマンドは名前ではなく数値でエンコードする必要があり、引数の形式はバイナリレベルで定義する必要があります。名前と単純なテキスト形式を使用すると、ソフトウェアの作成が容易になります。
反対方向に進むと、sysfs内のファイルを介してデバイスコンテンツへのアクセスを提供することが可能になります。ただし、これにはカーネルでの追加作業が必要になります。sysfsは、主に小さなファイルとシンボリックリンクを提供するように設計されており、既存のアプリケーションが期待するioctlサポートはありません。 sysfsを拡張して既存のデバイスタイプをサポートすることに大きなメリットはないと思います。したがって、デバイスファイルは引き続き存在します。
Sysfsはカーネルによって自動的に入力され、実際に利用可能なデバイスをリアルタイムで反映します。 sysfs内のファイルの意味は、そのファイルを提供するドライバーによって選択されるパスに由来します。 /devの動作は異なります。ファイルの意味は、デバイスファイルのタイプ（ブロックまたは文字）とそのメジャー番号とマイナー番号（デバイスのファイルサイズではなく、ls -lがリストするもの）に由来します。従来、/devは静的であり、システムのインストール中にデバイスファイルが作成されていました。ただし、デバイスをホットプラグできる場合はうまく機能しません。したがって、接続されたデバイスをリアルタイムで反映する動的な/devが必要です。
Linuxは、動的な/devを何度か繰り返しました。 Linux 2.4には devfs があり、カーネルは接続されたデバイスを反映するエントリを自動的に作成しました。しかし、それは それほど良くない でした。なぜなら、デバイスの名前付けとアクセス許可のポリシーをカーネルにハードコーディングしたため、ポリシーを管理するためにユーザーランドプログラム dev に置き換えられ、/dev単純なtmpfsファイルシステム（カーネルにとって特別な意味を持たないメモリ内ファイルシステム）。そして、devfsは devtmpfs で部分的にカムバックしました。これは、使用可能なデバイスのエントリがカーネルによって自動的に作成されるtmpfsのインスタンスですが、udevはその上で必要なすべての管理を行います。
カーネルドキュメントファイルから sysfs.txt ：
sysfsは、最初はramfsに基づいたRAMベースのファイルシステムです。カーネルデータ構造、それらの属性、およびそれらの間のリンクをユーザースペースにエクスポートする手段を提供します。
コミットメッセージ からカーネルソースへ：
Devtmpfsを使用すると、カーネルは、カーネルの初期化の非常に早い段階で、ドライバーコアデバイスが登録される前に、devtmpfsと呼ばれるtmpfsインスタンスを作成できます。メジャー/マイナーを持つすべてのデバイスは、devtmpfsにデバイスノードを提供します。
基本的に、sysfsは/sysにマウントされ、デバイスとデバイス名に関する情報と統計が含まれています。
devtmpfsは/devにマウントされ、すべてのデバイス用の特別なデバイスファイルが含まれています。