/procと/sysによるカーネル情報の公開機構

procfsとsysfs：ディスクを持たないファイルシステム

cat /proc/cpuinfo や cat /sys/class/net/eth0/mtu が値を返すとき、ディスク上のどこかにそのファイルが保存されているわけではありません。procfs（/proc）と sysfs（/sys）は、ストレージを一切持たない 仮想ファイルシステム（疑似ファイルシステム） です。ファイルへの read や write は、ディスクブロックの転送ではなく、カーネル内のコールバック関数を呼び出す操作に変換されます。つまり cat した瞬間に、その時点のカーネル状態から値が生成されて返ります。

これが可能なのは、両者が VFS（仮想ファイルシステム）層 の操作テーブル（関数ポインタの集合）を埋めるだけで「ファイルの世界」に参加できるからです。open/read/write という システムコール はそのまま使え、相手がディスク上のファイルか、カーネル変数への窓口かをユーザー空間は意識しません。ls や cat、echo > ファイル といった既存のツールが、そのままカーネルの観測・制御インターフェースになる——これが「すべてはファイル」という Unix 哲学を内部状態の公開に適用した姿です。

procfs：プロセスとカーネルの「何でも置き場」

procfs は元来 プロセス（process）情報 を公開するために生まれました。/proc/<pid>/ 以下に、各プロセスの状態が並びます。

ps や top の実装は、まさにこの /proc/<pid>/ を走査して情報を集めています。/proc/<pid>/fd/ がディスクリプタごとのシンボリックリンクとして見えるのは、ファイルディスクリプタ表 の中身を VFS のオブジェクトとして射影しているからです。

実装面では、procfs のファイルの多くは seq_file という仕組みの上に乗っています。read が来ると、登録された show 関数が呼ばれ、その場で行を組み立ててバッファへ流し込みます。値はディスクではなくカーネルのデータ構造（タスク構造体やグローバルカウンタ）から直接読み出されるため、常に最新です。/proc/sys/ 以下（sysctl）は書き込み可能で、echo 1 > /proc/sys/net/ipv4/ip_forward のような write がカーネル変数を更新するハンドラを起動します。

procfs の特徴は、1ファイルに整形済みの複合情報を載せる点にあります。/proc/meminfo は数十項目を人間が読める表として返し、/proc/<pid>/status も多数のフィールドを1ファイルに詰め込みます。便利な反面、機械的にパースしづらく、フォーマットが歴史的に増築されてきた経緯から 一貫した規約に欠ける——これが後発の sysfs を生む動機になりました。

sysfs：デバイスモデルを映す統一された木

sysfs は、Linux の デバイスモデル——デバイス・ドライバ・バス・クラスの関係——を、規律あるファイルツリーとして公開するために 2.6 系で導入されました。その背骨が kobject です。

kobject はカーネル内のオブジェクトに共通の「ハンドル」を与える基底構造で、参照カウント・名前・親へのリンクを持ちます。kobject 同士が親子リンクで木を成し、その木が そのまま sysfs のディレクトリ階層に対応します。つまり /sys を ls で辿る行為は、カーネル内 kobject グラフを歩くことと等価です。各ディレクトリ（kobject）にぶら下がる 属性（attribute） が個々のファイルになり、その show/store コールバックが読み書き時に呼ばれます。

kobject 階層            sysfs 上の見え方
  bus:pci         →   /sys/bus/pci/
    device 0000:00:1f.2  →   /sys/bus/pci/devices/0000:00:1f.2/
      attr "vendor"      →   .../vendor   (read: show()  が "0x8086\n" を生成)
      attr "enable"      →   .../enable   (write: store() がデバイスを有効化)

同じデバイスが複数の視点（どのバスに挿さっているか、どのクラスに属するか、ドライバは何か）から参照されるため、sysfs は シンボリックリンクを多用します。/sys/class/net/eth0 と /sys/devices/.../net/eth0 は同じ実体を別の切り口で指す、という構造です。デバイスモデルの全体像は デバイスドライバモデル で詳説しています。

属性の読み書きがカーネル状態を橋渡しする仕組み

両者に共通する核心は、ファイル操作と関数呼び出しの橋渡しです。属性ファイルには show（読み出し）と store（書き込み）の2つのコールバックが結び付いています。

read("/sys/class/net/eth0/mtu"):
    VFS が sysfs の read を呼ぶ
      → 属性に登録された show(kobj, buf) を実行
        → カーネル内の net_device->mtu を sprintf でテキスト化
      → ユーザー空間へ "1500\n" を返す

write("/sys/.../mtu", "9000"):
    VFS が sysfs の write を呼ぶ
      → store(kobj, buf, len) を実行
        → "9000" を整数へ変換し、検証してから dev->mtu を更新（実デバイスへ反映）

ここで重要なのは、store が 単なる値の保存ではなく、副作用を伴うアクションになり得る点です。echo 9000 > .../mtu はファイルに文字列を書くのではなく、MTU を変更するというデバイス操作を引き起こします。/proc/sys/vm/drop_caches への書き込みがキャッシュ解放を実行するのも同じ原理で、ファイルへの write がコマンド実行と等価になっています。だからこそ、これらのファイルへの書き込み権限はカーネルへの制御権限そのものであり、慎重な権限管理が要ります。

ユーザー空間がこれらの変更を待ち受ける手段もあります。sysfs の属性は poll/select に対応し、値の変化で待機中のプロセスを起こせます（例：電源やネットワークの状態監視）。procfs/sysfs が単なる読み出し窓口でなく、イベント通知や制御の経路も兼ねていることがわかります。

設計上の使い分け：いつどちらを使うか

両者は似て非なる役割を持ちます。新しいインターフェースをどちらに置くべきかは、公開する情報の性質で決まります。

実務上の指針はシンプルです。プロセスに固有の情報（/proc/<pid>/...）と歴史的に確立した sysctl は procfs に、デバイス・ドライバの属性は sysfs に置きます。新しいカーネル機能で「これは雑多な制御フラグだが procfs にも sysfs にも馴染まない」場合は、より自由度の高い debugfs（/sys/kernel/debug、デバッグ専用で ABI 安定性を保証しない）が選ばれることもあります。さらに、これらの仮想ファイルツリーは Linux名前空間とcgroups と連動し、PID 名前空間ごとに /proc の見え方が変わる（コンテナ内では自分の名前空間のプロセスしか見えない）など、隔離の文脈でも要となります。

まとめ

• procfs・sysfs はストレージを持たない仮想ファイルシステムで、ファイル操作が VFS 経由でカーネル内コールバックを呼び、値はアクセス時に生成される。cat/echo がそのまま観測・制御の手段になる。
• procfs はプロセス（/proc/<pid>）とカーネル全般の情報を扱う歴史的な何でも置き場で、1ファイルに整形済みの複合情報を載せる。ps/top の情報源であり、/proc/sys は sysctl の窓口。
• sysfs は kobject 階層に対応するデバイスモデルの木で、原則1ファイル1値・テキストという厳格な規約を持つ。show/store 属性が読み書きとカーネル状態を橋渡しし、write は副作用を伴うアクションになる。
• 使い分けは公開情報の性質で決まる。プロセス情報は procfs、デバイス属性は sysfs、ABI を保証しないデバッグ用途は debugfs、が大まかな指針。

土台は VFS層 と システムコール、デバイスモデルの全体像は デバイスドライバモデル、コンテナでの見え方は Linux名前空間とcgroups を合わせて読むと、これらの「ファイルに見えるカーネル」がどこに位置するかが立体的に見えてきます。