# Linuxカーネルインタフェース ## 定義 Linux カーネルインタフェースとは、Linux カーネルのサブシステムがユーザー空間プロセスへリソース・情報・サービスを提供し、またカーネルサブシステムの設定・チューニング・監視を可能にするための通信機構の総称である。理想的なインタフェースが持つべき 4 性質は、アーキテクチャ可搬性・イベントベース通知・拡張性・大規模データ転送効率である。Linux の主要インタフェースには、仮想ファイルシステム系(/dev・/proc・sysfs)と BSD ソケット系(ioctl・ソケットオプション・Netlink)が含まれる。(Source: [[@2010__SPE__Communicating between the kernel and user-space in Linux using Netlink sockets]]) ## 横断的知見 - **struct_ops/kfunc は 2010 年の Netlink 論文が定義した「拡張容易性」軸を、eBPF verifier という新しい安全機構で実現する後継インタフェースである**: [[@2010__SPE__Communicating between the kernel and user-space in Linux using Netlink sockets]] が整理した4性質(可搬性・イベント通知・拡張容易性・大規模転送)のうち、Netlink は「新しいプロトコルファミリを比較的容易に追加できる」拡張性を持っていた。[[cache_ext]]([[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]])が用いる `struct_ops`(カーネルサブシステムが関数ポインタコールバックを eBPF コンポーネントへ公開する機構)と kfunc(検証済みの型・境界チェック付きカーネル関数)は、Netlink とは異なる系譜(BPF verifier によるプログラム検証)から同じ「拡張容易性」を達成している。Netlink が「新しいメッセージ型を追加する」静的拡張だったのに対し、struct_ops/kfunc は「任意のロジック(eBPF プログラム)をカーネル内に安全にロードする」動的拡張であり、拡張性の実現手段がプロトコル設計から実行時検証へ移行したことを示す。(Source: [[@2010__SPE__Communicating between the kernel and user-space in Linux using Netlink sockets]], [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) - **struct_ops はカーネル内改変の「最小差分化」を担う共通パターンとして複数のサブシステムで再利用されている**: cache_ext は struct_ops を使うことで、page cache のコア変更を約 200 行に抑えつつ 5 種のイベントフック(policy_init・evict_folios・folio_added・folio_accessed・folio_removed)を追加した。同じ struct_ops 機構は TCP 輻輳制御・FUSE BPF ファイルシステム・HID デバイス挙動補正・パケットスケジューリング・[[sched_ext]] でも使われており、「カーネルサブシステムに新しい verifier 変更なしでコールバック群を追加する」という拡張手法が Linux カーネル全体で反復されるデザインパターンになっていることを cache_ext の実装が定量的に裏付けた。(Source: [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]]) - **eBPF マップの「大規模転送」性質は、マップ型ごとに設計トレードオフを伴う実測データで裏付けられる**: [[@2024__eBPF'24__Understanding Performance of eBPF Maps]] は、eBPF マップの中でもユーザ空間への「大規模データ転送」を担う ring buffer と perf buffer を比較し、ring buffer の reserve+submit 方式(予約済みメモリ領域へ直接書き込みメモリコピーを削減)が perf buffer より一貫して低いオーバーヘッドを示すことを実測した。これは本ページの Table I が eBPF マップ全体を単に「Yes」1語で評価していた「大規模転送」軸を、マップ型間の設計差(コピー回数)による定量的な優劣として初めて具体化するものであり、[[eBPFマップ]] の性能特性が Netlink の4性質フレームワークにおける「大規模転送」区分の内部にさらに粒度の細かいトレードオフを持つことを示す。(Source: [[@2024__eBPF'24__Understanding Performance of eBPF Maps]]) ## 未解決の問い - /proc・sysfs はカーネルバージョンによって ABI の安定性がどう変化したか? - BPF_PROG_QUERY はこの分類フレームワークのどこに位置づけられるか? - io_uring は「大規模データ転送」の代替として Netlink と比較されているか? - ioctl は 2024 年現在の Linux カーネルでどの程度新規追加されているか? Netlink への移行は完了したか? - struct_ops/kfunc ベースの拡張(cache_ext・sched_ext)は、Netlink の4性質フレームワーク(可搬性・イベント通知・拡張容易性・大規模転送)でどう評価されるか? [[@2024__eBPF'24__Understanding Performance of eBPF Maps]] は ring buffer/perf buffer 間の転送効率差を実測データで示したが、array/hash 等の他のマップ型やマップ全体としての Netlink との定量比較(スループット・レイテンシ)はまだ行われていない。表を更新して整理する価値がある。 ## 主要インタフェースの比較(Table I より、2010 年時点) | インタフェース | アーキテクチャ可搬性 | イベント通知 | 拡張容易性 | 大規模転送 | |---|---|---|---|---| | システムコール | No | No(限定的) | No | Yes | | /dev | No | No | No | Yes | | /proc | Yes(テキスト) | No | No | No | | Sysfs | Yes(テキスト) | Yes(Netlinkを使用) | No | No | | ソケット(Netlink除く) | No | No | No | Yes | | Netlink | Yes | Yes | Yes | Yes | ## 関連 - [[Netlinkソケット]] — 4 性質すべてを満たす Linux の代表的カーネルインタフェース - [[eBPF]] — 現代のカーネル-ユーザー空間計装手段。struct_ops/kfunc による拡張容易性の実現手段 - [[eBPFマップ]] — eBPF プログラムのデータ保存・通信手段。「大規模転送」性質の実装レベルの根拠 - [[cache_ext]] / [[sched_ext]] — struct_ops/kfunc を用いてカーネル方針そのものを拡張するインタフェースの実例 - [[@2004__USENIX-ATC__Dynamic Instrumentation of Production Systems]] — DTrace は Solaris での同類の問いを扱う ## 出典 - [[@2010__SPE__Communicating between the kernel and user-space in Linux using Netlink sockets]] - [[@2026__TOCS__cache_ext - Customizing and Tracing the Page Cache with eBPF]](struct_ops/kfunc によるページキャッシュ拡張。page cache コア変更を約200行に抑制) - [[@2024__eBPF'24__Understanding Performance of eBPF Maps]](eBPF マップの網羅的性能ベンチマーク。ring buffer/perf buffer の大規模転送効率差を実測)