LCTT 譯注：昨天，AlmaLinux 稱將 放棄 對 RHEL 的 1:1 兼容性，但將保持對 RHEL 的 ABI 兼容，以便在 RHEL 上運行的軟件可以無縫地運行在 AlmaLinux 上。可能有的同學對 ABI 的概念還不是很清楚，因此翻譯此文供大家了解。

許多 Linux 愛好者都熟悉 Linus Torvalds 的 著名告誡：“我們不破壞用戶空間”，但可能并非每個聽到這句話的人都清楚其含義。

這個“第一規則”提醒開發人員關于應用程序的二進制接口（ABI）的穩定性，該接口用于應用程序與內核之間的通信和配置。接下來的內容旨在使讀者熟悉 ABI 的概念，闡述為什么 ABI 的穩定性很重要，并討論 Linux 穩定 ABI 中包含了哪些內容。Linux 的持續增長和演進需要對 ABI 進行變更，其中一些變更引起了爭議。

什么是 ABI？

ABI 表示 應用程序二進制接口Applications Binary Interface。理解 ABI 概念的一種方式是考慮它與其他概念的區別。對于許多開發人員來說，應用程序編程接口Applications Programming Interface（API）更為熟悉。通常，庫的頭文件和文檔被認為是其 API，以及還有像 HTML5 這樣的標準文檔。調用庫或交換字符串格式數據的程序必須遵守 API 中所描述的約定，否則可能得到意外的結果。

ABI 類似于 API，因為它們規定了命令的解釋和二進制數據的交換方式。對于 C 程序，ABI 通常包括函數的返回類型和參數列表、結構體的布局，以及枚舉類型的含義、順序和范圍。截至 2022 年，Linux 內核仍然幾乎完全是 C 程序，因此必須遵守這些規范。

“內核系統調用接口” 的描述可以在《Linux 手冊第 2 節》中找到，并包括了可從中間件應用程序調用的類似 mount 和 sync 的 C 版本函數。這些函數的二進制布局是 Linux ABI 的第一個重要組成部分。對于問題 “Linux 的穩定 ABI 包括哪些內容？”，許多用戶和開發人員的回答是 “sysfs（/sys）和 procfs（/proc）的內容”。而實際上，官方 Linux ABI 文檔 確實主要集中在這些 虛擬文件系統 上。

前面著重介紹了 Linux ABI 在程序中的應用方式，但未涵蓋同等重要的人為因素。正如下圖所示，ABI 的功能需要內核社區、C 編譯器（如 GCC 或 clang）、創建用戶空間 C 庫（通常是 glibc）的開發人員，以及按照 可執行與鏈接格式（ELF） 布局的二進制應用程序之間的合作努力。

開發社區內的合作

為什么我們關注 ABI？

來自 Torvalds 本人的 Linux ABI 的穩定性保證，使得 Linux 發行版和個人用戶能夠獨立更新內核，而不受操作系統的影響。

如果 Linux 沒有穩定的 ABI，那么每次內核需要修補以解決安全問題時，操作系統的大部分甚至全部內容都需要重新安裝。顯然，二進制接口的穩定性是 Linux 的可用性和廣泛采用的重要因素之一。

Terminal output

如上圖所示，內核（在 linux-libc-dev 中）和 Glibc（在 libc6-dev 中）都提供了定義文件權限的位掩碼。顯然，這兩個定義集必須一致！apt 軟件包管理器會識別軟件包提供每個文件。Glibc ABI 的潛在不穩定部分位于 bits/ 目錄中。

在大部分情況下，Linux ABI 的穩定性保證運作良好。按照 

Y2038：一個 ABI 破壞的例子

通過考慮當前正在進行的、緩慢發生 的 “Y2038” ABI 破壞的例子，可以更好地理解 Linux ABI。在 2038 年 1 月，32 位時間計數器將回滾到全零，就像較舊車輛的里程表一樣。2038 年 1 月聽起來還很遙遠，但可以肯定的是，如今銷售的許多物聯網設備仍將處于運行狀態。像今年安裝的 智能電表 和 智能停車系統 這樣的普通產品可能采用的是 32 位處理器架構，而且也可能不支持軟件更新。

Linux 內核已經在內部轉向使用 64 位的 time_t 不透明數據類型來表示更晚的時間點。這意味著像 time() 這樣的系統調用在 64 位系統上已經變更了它們的函數簽名。這些努力的艱難程度可以在內核頭文件中（例如 time_types.h）清楚地看到，在那里放著新的和 _old 版本的數據結構。

里程表翻轉

Glibc 項目也 支持 64 位時間，那么就大功告成了，對嗎？不幸的是，根據 Debian 郵件列表中的討論 來看，情況并非如此。發行版面臨難以選擇的問題，要么為 32 位系統提供所有二進制軟件包的兩個版本，要么為安裝介質提供兩個版本。在后一種情況下，32 位時間的用戶將不得不重新編譯其應用程序并重新安裝。正如往常一樣，專有應用程序才是一個真正的頭疼問題。

Linux 穩定 ABI 里到底包括什么內容？

理解穩定 ABI 有些微妙。需要考慮的是，盡管大部分 sysfs 是穩定 ABI，但調試接口肯定是不穩定的，因為它們將內核內部暴露給用戶空間。Linus Torvalds 曾表示，“不要破壞用戶空間”，通常情況下，他是指保護那些 “只想它能工作” 的普通用戶，而不是系統程序員和內核工程師，后者應該能夠閱讀內核文檔和源代碼，以了解不同版本之間發生了什么變化。下圖展示了這個區別。

穩定性保證

普通用戶不太可能與 Linux ABI 的不穩定部分進行交互，但系統程序員可能無意中這樣做。除了 /sys/kernel/debug 以外，sysfs（/sys）和 procfs（/proc）的所有部分都是穩定的。

那么其他對用戶空間可見的二進制接口如何呢，包括 /dev 中的設備文件、內核日志文件（可通過 dmesg 命令讀取）、文件系統元數據或在內核的 “命令行” 中提供的 “引導參數”（在引導加載程序如 GRUB 或 u-boot 中可見）呢？當然，“這要視情況而定”。

掛載舊文件系統

除了 Linux 系統在引導過程中出現掛起之外，文件系統無法掛載是最令人失望的事情。如果文件系統位于付費客戶的固態硬盤上，那么問題確實十分嚴重。當內核升級時，一個能夠在舊內核版本下掛載的 Linux 文件系統應該仍然能夠掛載，對嗎？實際上，“這要視情況而定”。

在 2020 年，一位受到傷害的 Linux 開發人員在內核的郵件列表上 抱怨道：

內核已經接受這個作為一個有效的可掛載文件系統格式，沒有任何錯誤或任何類型的警告，而且已經這樣穩定地工作了多年……我一直普遍地以為，掛載現有的根文件系統屬于內核<->用戶空間或內核<->現有系統邊界的范圍，由內核接受并被現有用戶空間成功使用的內容所定義，升級內核應該與現有用戶空間和系統兼容。

但是有一個問題：這些無法掛載的文件系統是使用一種依賴于內核定義，但并未被內核使用的標志的專有工具創建的。該標志未出現在 Linux 的 API 頭文件或 procfs/sysfs 中，而是一種 實現細節。因此，在用戶空間代碼中解釋該標志意味著依賴于“未定義行為”，這是個幾乎會讓每個軟件開發人員都感到戰栗的短語。當內核社區改進其內部測試并開始進行新的一致性檢查時，“man 2 mount” 系統調用突然開始拒絕具有專有格式的文件系統。由于該格式的創建者明確是一位軟件開發人員，因此他未能得到內核文件系統維護者的同情。

施工標志上寫著工作人員在樹上進行工作

線程化內核的 dmesg 日志

/dev 目錄中的文件格式是否保證穩定或不穩定？dmesg 命令 會從文件 /dev/kmsg 中讀取內容。2018 年，一位開發人員 為 dmesg 輸出實現了線程化，使內核能夠“在打印一系列 printk() 消息到控制臺時，不會被中斷和/或被其他線程的并發 printk() 干擾”。聽起來很棒！通過在 /dev/kmsg 輸出的每一行添加線程 ID，實現了線程化。密切關注的讀者將意識到這個改動改變了 /dev/kmsg 的 ABI，這意味著解析該文件的應用程序也需要進行相應的修改。由于許多發行版沒有編譯啟用新功能的內核，大多數使用 /bin/dmesg 的用戶可能沒有注意到這件事，但這個改動破壞了 GDB 調試器 讀取內核日志的能力。

確實，敏銳的讀者會認為 GDB 的用戶運氣不佳，因為調試器是開發人員工具。實際上并非如此，因為需要更新以支持新的 /dev/kmsg 格式的代碼位于內核自己的 Git 源代碼庫的 “樹內” 部分。對于一個正常的項目來說，單個代碼庫內的程序無法協同工作就是一個明顯的錯誤，因此已經合并了一份 使 GDB 能夠與線程化的 /dev/kmsg 一起工作的補丁。

那么 BPF 程序呢？

BPF 是一種強大的工具，可以在運行的內核中監控甚至實時進行配置。BPF 最初的目的是通過允許系統管理員即時從命令行修改數據包過濾器，從而支持實時網絡配置。Alexei Starovoitov 和其他人極大地擴展了 BPF，使其能夠跟蹤任意內核函數。跟蹤明顯是開發人員的領域，而不是普通用戶，因此它顯然不受任何 ABI 保證的約束（盡管 bpf() 系統調用 具有與其他系統調用相同的穩定性承諾）。另一方面，創建新功能的 BPF 程序為“取代內核模塊成為擴展內核的事實標準手段”提供了可能性。內核模塊使設備、文件系統、加密、網絡等工作正常，因此明顯是“只希望它工作”的普通用戶所依賴的設施。問題是，與大多數開源內核模塊不同，BPF 程序傳統上不在內核源代碼中。

2022 年春季，一個提案 成為了焦點，該提案提議使用微型 BPF 程序而不是設備驅動程序補丁，對廣泛的人機接口設備（如鼠標和鍵盤）提供支持。

隨后進行了一場激烈的討論，但這個問題顯然在 Torvalds 在開源峰會上的評論 中得到解決：

他指出，如果你破壞了“普通（非內核開發人員）用戶使用的真實用戶空間工具”，那么你需要修復它，無論是否使用了 eBPF。

一致意見似乎正在形成，即希望其 BPF 程序在內核更新后仍能正常工作的開發人員 將需要將其提交到內核源代碼庫中一個尚未指定的位置。敬請關注后繼發展，以了解內核社區對于 BPF 和 ABI 穩定性將采取什么樣的政策。

結論

內核的 ABI 穩定性保證適用于 procfs、sysfs 和系統調用接口，但也存在重要的例外情況。當內核變更破壞了“樹內”代碼或用戶空間應用程序時，通常會迅速回滾有問題的補丁。對于依賴內核實現細節的專有代碼，盡管這些細節可以從用戶空間訪問，但它并沒有受到保護，并且在出現問題時得到的同情有限。當像 Y2038 這樣的問題無法避免 ABI 破壞時，會以盡可能慎重和系統化的方式進行過渡。而像 BPF 程序這樣的新功能提出了關于 ABI 穩定性邊界的尚未解答的問題。

致謝

感謝 Akkana Peck、Sarah R. Newman 和 Luke S. Crawford 對早期版本材料的有益評論。