RHEL 內核與第三方模組編譯

無論是出於什麼樣的原因而使用了 RHEL（或者其複製品），這款發行版在使用上的一項挑戰，就是它字面上的 Linux 內核版本，無法準確地反映出它實際的內核狀況。比方說 RHEL 9 的內核版本乍看之下為 5.14，但它實際上還包含了許多由 Red Hat 從其它較新的內核版本裡所移植的異動。這使得第三方的內核模組，比方說特定硬體裝置的驅動程式，倘若要妥善地支援及應對 RHEL 的內核變化，基本上很難不透過一連串的試錯（排除編譯錯誤），以及加入許多額外的條件判斷來實現。

舉例來說，前陣子 DR 對於 8821au.ko 驅動程式所做的一輪修改，即體現出這類工程的特殊處境。從中可以看到，就 RHEL 內核的情況而言，第三方驅動程式的原始碼若僅僅依賴內核版本來作為判斷，是不太準確的；而必須再加上 RHEL 版本的識別，來作為判斷方式。同時也能夠看到，在 RHEL 所提供的內核原始碼標頭（來自 kernel-devel 套件）裡，linux/version.h 這支標頭檔即存放著所有可用於識別 RHEL 版本的相關資訊。在命令行下可以使用以下指令來檢視：

• cat /usr/src/kernels/$(uname -r)/include/generated/uapi/linux/version.h

其中所定義的 RHEL_MAJOR 即為 RHEL 的主版本（例如 9.5 中的 9）、RHEL_MINOR 為子版本（例如 9.5 中的 5）、以及 RHEL_RELEASE 則為 RHEL 內核異動所備註的版本號（例如 5.14.0-503.15.1 中的 503.15.1）。RHEL_MINOR 與 RHEL_RELEASE 在實務上的意義類似，可以在需要時，用於做出更針對於特定版本區間的條件判斷。

在 RHEL 所規劃的 10 年維護週期裡，前 5 年的完整支援期間（Full Support Phase）仍會有子版本的發佈。也就代表著內核版本可能仍會伴隨著一些較大的功能異動，第三方模組的原始碼必須得與時俱進，才能夠保障相容性。然而後 5 年的維護支援期間（Maintenance Support Phase），內核異動就會處於相對低幅度的狀態，第三方模組可能就不再有必要進行修改。例如此時的 RHEL 8 內核，相較於 RHEL 9 的情形。

另一方面，在 RHEL 的完整支援期間裡，作為其開發上游的 CentOS Stream 發行版，也有助於讓第三方模組的開發者能夠提前接觸到 RHEL 後續可能會有的變化。以及在 CentOS Stream 的 GitLab 專案庫裡，開發者也能夠藉此檢視 RHEL 內核版本更新的原始碼異動，比起 RHEL 對外發佈的原始碼套件，有可能是更加便利的研究途徑。