カーネル開発者は、カーネル機能を公開するときにいくつかのオプションを使用できます。新しいシステムコールを作成したり、/sysまたは/procエントリを介して機能を公開したりできます。
他のものより1つを選ぶ理由はありますか？
カーネル開発者は、かなりの利点を提供しない限り、新しいシステムコールを追加することを避けますか、それとも必要に応じて自由にコールを追加しますか？
編集する：私はnetfilter機能をLinuxコンテナ（LXC）に公開するプロジェクトを進めています。機能は制御された方法で公開する必要があります。たとえば、コンテナ（c1など）がnetfilterフックを配置したい場合は、パケットがc1のネットワークインターフェイス用に意図されている場合にのみフックを呼び出す必要があります。
新しいシステムコールを作成したり、コンテナがモジュールをインストールしたり、ゲストインストールカーネルモジュールからホストカーネルを保護したりするために、カーネルに変換レイヤを提供できます。 （この翻訳モジュールの実装またはコンテナがモジュールをインストールできるようにするセキュリティ影響は、別の議論の主題になる可能性があります。）
新しいシステムコールを追加すると、より良い分離が保証され、ゲストがモジュールをインストールできるようにすることでパフォーマンスが向上します。後者は、たとえば、ゲストが独自のバージョンのTCP / IPスタックを使用したい場合にシステムコールが実行できない機能を公開する可能性があります。
経験豊富なLinuxカーネル開発者は何を好みますか？
ベストアンサー1
新しいシステムコールはほとんど追加されません。ほとんどの新しいカーネル機能は、いくつかの一般的なメカニズムによって実装できます。
- ファイル記述子は、リソース管理の非常に一般的な機能です。
- ファイル記述子に対するカスタム操作が渡されます。
ioctl。 - インタラクションは次の方法でも可能です。プロセスファイルシステムそしてその変種システムファイルシステムハードウェアとドライバに関する情報です。
これらの一般的なメカニズムは、既存の一般的なサポートの利点を利用します。たとえば、記述子に関連付けられているリソースは子プロセスと自動的に共有され、そうするようにexecve指示された場合は自動的に閉じられ、記述子が閉じられたとき（プロセスが終了したときに発生）が解放されます。ファイルで実装された新機能へのアクセス制御は、洗練されたファイルアクセス制御メカニズム（権限、SELinuxなど）によって提供されます。
これらの一般的なメカニズムは、ライブラリのサポートを待たずにすぐに使用できるため、新しいシステムコールよりも使いやすくなります。/proc新しいエントリはシェルスクリプトで直接使用できます。新機能はioctlアプリで直接利用できます。標準ライブラリで新しいシステムコールを宣言する必要があります。
これシステムコールのマニュアルページ各システムコールが追加されたカーネルバージョンを一覧表示します。ほとんどの新しいシステムコールは、メタデータと資格情報（2.6の拡張属性のサポートなど）を管理するか、以前は不可能であった操作のバリエーション（たとえば）execveatとして特定の種類のファイルに対して機能する新しい方法を提供しますrenameat2。