これはおそらくカーネルヘッダに関する一貫性のない質問です。なぜなら、カーネルヘッダーがどこでどのように使用されているのかを明確に理解していないからです。私の考えにはフラグが付くかもしれないと思います。私の質問は3つの部分で構成されています。
カーネルヘッダは、カーネルの他の部分（モジュールなど）が使用できるようにインタフェースを提供すると思います。これが私の本の知識です。私はカーネルヘッダを使用するコードを見たことも見つかったこともありません（誰が指摘してくれてありがとう）。ユーザースペースでも使用できますか？すべてのコード例を高く評価します。
カーネルヘッダーの使用は
make headers_installユーザースペースによって公開されますが、同時にユーザースペースでカーネルヘッダーを使用することはお勧めできません。推奨されない場合は、ユーザースペースに公開するのに何が役に立ちますか？~によるとこれそしてこれ、カーネルヘッダーファイル（.hファイル）は、
/usr/include/linux/kernel.hユーザースペースの3つの場所になければなりません。 b。/lib/modules/$(uname -r)/build/include/linux/sched.hこれは外部モジュールです。/usr/src/...カーネルモジュールの場合、これは、異なるディレクトリのヘッダファイルが異なる目的を持っているか、インタフェースや署名が異なることを意味しますか？つまり、#include <linux/xyz.h>ユーザー空間コードの意味は#include <linux/xyz.h>カーネルモジュールの意味とは異なりますか？外部モジュールはカーネルモジュールと同じですか？
ありがとうございます。
ベストアンサー1
UnixとLinux StackExchangeへようこそ！
はい、カーネルヘッダはカーネルの残りの部分へのインタフェースを提供します。その点では完全に正しいです。カーネルとユーザー空間の間のインタフェース定義も含まれていますが、通常は「生」カーネルインタフェースを直接使用せず（通常glibc）Cライブラリを介して使用します。
以前のバージョンとの互換性のために、ユーザ空間カーネルインタフェースには、特定のシステムコールの複数のバージョンを含めることができます。 Cライブラリを介してシステムコールを実行すると、すべてのアプリケーションが実際のシステムコールと同じバージョンを取得するため、一貫した動作が保証されます。また、カーネルインターフェイスの関連部分が更新されたら、Cライブラリのみを更新して新しい機能を利用できます。
（たとえば、Y2K38の問題を回避するために、time_tが32ビットアーキテクチャで64ビットに拡張されている場合、Cライブラリは常に64ビットバージョンのカーネルインターフェイスを使用できますが、ユーザースペース設定可能アプリケーションマッピングでは32ビットバージョンを使用します。 time_t関数は廃止され、カーネルから削除される可能性があり、Cライブラリはまだ32ビットタイプを使用する従来のアプリケーションに対してより良い解決策を提供できます。
したがって、Cライブラリで独自のバージョンをコンパイルしない限り、通常はカーネルヘッダを直接使用するよりも、Cライブラリの開発ヘッダを好む必要があります。
ヘッダファイルは/usr/include/linux/通常、Cライブラリの開発ヘッダパッケージに付属しており、Cライブラリがコンパイルされたカーネルバージョンを記述します。これは通常、ユーザー空間アプリケーション開発者に必要です。
/lib/modules/$(uname -r)/build/usr/src/...通常、実際に実行されているカーネルバージョンのヘッダーまたはソースコード全体が格納されている場所へのシンボリックリンク。外部（サードパーティとも呼ばれる）カーネルモジュール、つまりデフォルトのカーネルソースコードに統合されていないソースのカーネルモジュールをコンパイルするときに使用されます。これらのヘッダーには、モジュールがバージョン固有のカーネル内部 API を使用できるようにするために必要なカーネル API バージョン署名が含まれています。