這可能是一個關於核心頭的不連貫的問題，因為我對它以及它的使用地點和方式沒有清楚的了解。我認為它可能會被標記。我的問題有 3 個部分：
我認為內核頭提供了一個接口，以便內核的其他部分（例如模組）可以使用它們。這就是我的書本知識。我還沒有看到或發現任何使用內核頭的程式碼（如果有人能指出我，我將不勝感激）。它也可以在用戶空間中使用嗎？任何程式碼範例將不勝感激。
我發現使用
make headers_install核心頭是由用戶空間公開的，但同時不鼓勵在用戶空間中使用核心頭。如果不鼓勵，那麼將其暴露給用戶空間有什麼用呢？按照這和這，核心頭檔（.h 檔案）應該位於 3 個位置：
/usr/include/linux/kernel.h用於使用者空間 b．/lib/modules/$(uname -r)/build/include/linux/sched.h這是外部模組 c./usr/src/...用於內核模組這是否意味著不同目錄中的頭檔具有不同的用途或不同的介面或簽名？換句話說，#include <linux/xyz.h>使用者空間程式碼中的意義與#include <linux/xyz.h>核心模組中的意義是否不同？外部模組與核心模組相同嗎？
謝謝。
答案1
歡迎來到 Unix 和 Linux StackExchange！
是的，內核頭檔為內核的其他部分提供了一個介面——在這一點上你是完全正確的。它們還包括內核和用戶空間之間接口的定義 - 但通常不直接使用“原始”內核接口，而是透過 C 庫（通常glibc）使用。
出於向後相容性的原因，使用者空間-核心介面可以包括特定係統呼叫的多個版本。透過 C 庫進行系統調用，所有應用程式都會獲得相同版本的實際系統調用，從而保證行為的一致性。此外，當核心介面的相關部分更新時，您只需更新 C 庫即可利用新功能。
（例如，當 time_t 在 32 位元架構中擴展到 64 位元以避免 Y2K38 問題時，C 庫可能會始終使用 64 位元版本的內核接口，但具有用戶空間可配置的應用程式映射那時，使用32 位元time_t的函數可以被廢棄並從核心中刪除，並且C 庫可以為仍然使用32 位元類型的遺留應用程式提供更好的解決方法。
因此，除非您也在 C 庫中編譯自己的版本，否則您通常應該更喜歡 C 庫的開發頭文件，而不是直接使用內核頭文件。
頭檔/usr/include/linux/通常與 C 庫的開發頭包一起提供，並描述 C 庫編譯的內核版本。這是用戶空間應用程式開發人員通常需要的。
/lib/modules/$(uname -r)/build/usr/src/...通常是指向實際運行的核心版本的標頭或完整原始碼儲存位置的符號連結。它在編譯外部（也稱為第三方）核心模組時使用，即來自未整合到主核心原始碼的來源的核心模組。這些標頭包含必要的核心 API 版本簽名，以便模組可以使用特定版本的核心內部 API。