少なくとも実装の詳細が必要ない場合は、実際には非常に簡単です。
まず、Linux では、すべてのファイル システム (ext2、ext3、btrfs、reiserfs、tmpfs、zfs など) がカーネルに実装されています。 FUSE を介して作業をユーザーランド コードにオフロードするものもあれば、カーネル モジュールの形式でのみ提供されるものもあります (ライセンスの制限により、ネイティブ ZFS は後者の顕著な例です)。いずれにしても、カーネル コンポーネントは残ります。これは重要な基本です。
プログラムがファイルから読み取りたい場合、さまざまなシステム ライブラリ呼び出しが発行され、最終的に open() の形式でカーネルに格納されます。 、 read() 、 close() シーケンス (おそらく seek() を使用) かなりの量で投入されます）。カーネルは提供されたパスとファイル名を取得し、ファイル システムとデバイス I/O レイヤーを介して、これらを基盤となるストレージへの物理的な読み取り要求 (および多くの場合、書き込み要求 - たとえば atime 更新など) に変換します。
ただし、これらのリクエストを具体的に物理的、永続的に変換する必要はありません ストレージ .カーネルの契約では、特定のシステム コール セットを発行すると、問題のファイルの内容が提供される . 「ファイル」が存在する物理領域の正確な場所は、これに次ぐものです。
/proc で 通常、procfs と呼ばれるものがマウントされます .これは特殊なファイル システム タイプですが、ファイル システムであるため、たとえば、 ext3 ファイルシステムはどこかにマウントされています。そのため、リクエストは procfs ファイル システム ドライバ コードに渡されます。このコードは、これらすべてのファイルとディレクトリを認識し、カーネル データ構造から特定の情報を返します。 .
この場合の「ストレージ層」はカーネルのデータ構造であり、procfs それらにアクセスするためのクリーンで便利なインターフェースを提供します。 /proc で procfs をマウントすることに注意してください。 単なる慣習です。他の場所に簡単にマウントできます。実際、chroot 監獄で実行中のプロセスが何らかの理由で /proc にアクセスする必要がある場合などに、これが行われることがあります。
ファイルに値を書き込む場合も同様に機能します。カーネルレベルでは、一連の open() に変換されます 、 seek() 、 write() 、 close() 再びファイル システム ドライバーに渡される呼び出し。繰り返しますが、この特定のケースでは、procfs コードです。
file が表示される特定の理由 empty を返す procfs によって公開されるファイルの多くは、0 バイトのサイズで公開されます。 0 バイト サイズはおそらくカーネル側の最適化です (/proc 内のファイルの多くは動的であり、おそらく 1 回の読み取りから次の読み取りまで、長さが簡単に変化する可能性があり、ディレクトリ読み取りごとに各ファイルの長さを計算すると、非常に高価になる可能性があります）。 strace または同様のツール file を実行して、独自のシステムで確認できるこの回答へのコメントを参照してください。 最初に stat() を発行します を呼び出して特別なファイルを検出し、ファイル サイズが 0 と報告された場合は中止し、ファイルが空であると報告します。
この動作は実際に文書化されており、-s を指定することでオーバーライドできます または --special-files file で 呼び出し、 マニュアルページに記載されているように、副作用がある可能性があります。以下の引用は、2011 年 10 月 17 日付けの BSD ファイル 5.11 のマニュアル ページからのものです。
通常、file は、stat(2) が通常のファイルであると報告する引数ファイルのタイプを読み取って判別しようとするだけです。これにより、特殊ファイルを読み取ると特殊な結果が生じる可能性があるため、問題が回避されます。 -s の指定 オプションを指定すると、 file は、ブロックまたは文字特殊ファイルである引数ファイルも読み取ります。これは、ブロック スペシャル ファイルである raw ディスク パーティション内のデータのファイル システム タイプを判別するのに役立ちます。 また、このオプションにより、file は stat(2) によって報告されたファイル サイズを無視します 一部のシステムでは、raw ディスク パーティションのサイズがゼロと報告されるためです。
このディレクトリでは、カーネルがデバイスを表示する方法を制御し、カーネル設定を調整し、デバイスをカーネルに追加して再度削除することができます。このディレクトリでは、メモリ使用量と I/O 統計を直接表示できます。
どのディスクがマウントされ、どのファイル システムが使用されているかを確認できます。つまり、何を探すべきか分かっていれば、このディレクトリから Linux システムのすべての側面を調べることができます。
/proc directory は通常のディレクトリではありません。ブート CD から起動し、ハード ドライブのそのディレクトリを見ると、空であることがわかります。通常の実行中のシステムで見ると、かなり大きくなる可能性があります。ただし、ハードディスク領域を使用していないようです。これは、仮想ファイル システムであるためです。
/proc 以降 ファイル システムは仮想ファイル システムであり、新しい /proc というメモリ内に常駐します。 ファイル システムは、Linux マシンが再起動するたびに作成されます。
言い換えれば、ファイルおよびディレクトリ タイプのインターフェイスを介して、Linux システムの根幹を簡単にのぞき見するための手段にすぎません。 /proc 内のファイルを見ると、 ディレクトリでは、Linux カーネル内のメモリの範囲を直接見て、何が見えるかを確認しています。
ファイル システムのレイヤー
例:
/procの内部 、実行中のプロセスごとに、そのプロセス ID で名前が付けられたディレクトリがあります。これらのディレクトリには、次のようなプロセスに関する有用な情報を含むファイルが含まれています。exe:プロセスが開始されたディスク上のファイルへのシンボリック リンクです。cwd:プロセスの作業ディレクトリへのシンボリック リンクです。wchan:読み取られると、プロセスがオンになっている待機チャネルを返します。maps:読み取り時に、プロセスのメモリ マップを返します。
/proc/uptime アップタイムを、スペースで区切られた秒単位の 2 つの 10 進数値として返します:- カーネルが起動してからの時間
- カーネルがアイドル状態だった時間
/proc/interrupts :割り込みに関する情報/proc/modules :モジュールのリスト。詳細については、man proc または kernel.org を参照してください。
あなたは正しいです、それらは実際のファイルではありません。
簡単に言うと、カーネルを直接呼び出すのではなく、通常のファイルの読み書き方法を使用してカーネルと対話する方法です。これは、Unix の「すべてはファイルである」という哲学に沿っています。
/proc のファイル 物理的にどこにも存在しませんが、カーネルはそこで読み書きするファイルに反応し、ストレージに書き込む代わりに、情報を報告したり、何かをしたりします.
同様に、/dev のファイル 従来の意味でのファイルではありません (一部のシステムでは、/dev のファイルは 実際にはディスク上に存在する可能性がありますが、それらが参照するデバイス以外にはあまりありません) - 通常の Unix ファイル I/O API を使用してデバイスと通信することができます - またはシェルなど、それを使用するものは何でも