Ulrich Dangelは、devtmpfsとudevの違いを非常によく説明しています。
sysfsはどうですか？
カーネルがsysfsを使用して、udevで使用されるユーザースペースにデバイスノードをエクスポートすることを理解しています。では、devtmpfsとsysfsは同じですか？はいの場合、なぜ彼らは異なる名前を使用するのですか？いいえの場合、sysfsとdevtmpfsの本当の違いは何ですか？
承認された回答：
カーネルはsysfsを使用して、デバイスノードをudevが使用するユーザースペースにエクスポートします
いいえ。Sysfsにはデバイスノードは含まれていません。 Sysfsには主に、デバイスに関する情報を提供するファイルと、プロセスがデバイスの動作を制御できるようにするファイルが含まれています。ただし、ほとんどの場合、sysfsが提供するものを介してデバイスを使用することはできません。
ハードディスクを例にとってみましょう。 / sys / devicesの下のどこかにそのディレクトリがあります 、コンピュータへの接続方法に応じたパスを使用します（例： / sys / devices / pci0000：00/… コンピュータのプライマリPCIバスに接続されているコントローラに接続されているディスクの場合）。そのディレクトリには、サイズ、リムーバブルかどうか、電源状態などのさまざまな情報があります。パーティションのサブディレクトリもあります。しかし、ディスクのコンテンツへのアクセスを提供するものは何もありません。 / 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 </ code>）に由来します。 デバイスのファイルサイズの代わりにリスト）。従来、 / dev 静的であり、システムのインストール中にデバイスファイルが作成されました。ただし、デバイスをホットプラグできる場合はうまく機能しないため、動的な / devが必要です。 接続されたデバイスをリアルタイムで反映します。
Linuxは、動的な / devを何度か繰り返してきました。 。 Linux 2.4にはdevfsがあり、カーネルは接続されたデバイスを反映するエントリを自動的に作成しました。しかし、デバイスの名前付けとアクセス許可のポリシーをカーネルにハードコーディングしたため、ポリシーを管理するためのユーザーランドプログラムudevと / dev に置き換えられたため、これはあまり良くありませんでした。 単純なtmpfsファイルシステム（カーネルにとって特別な意味を持たないメモリ内ファイルシステム）。そして、devfsは、使用可能なデバイスのエントリがカーネルによって自動的に作成されるtmpfsのインスタンスであるdevtmpfsを使用して部分的にカムバックしましたが、udevはその上で必要なすべての管理を行います。