十分鐘讓你了解 Linux ABI-魔扣目錄

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 的穩定性保證運作良好。按照?康韋定律Conway’s Law，在開發過程中出現的煩人技術問題往往是由于不同軟件開發社區之間的誤解或分歧所致，而這些社區都為 Linux 做出了貢獻。不同社區之間的接口可以通過 Linux 包管理器的元數據輕松地進行想象，如上圖所示。

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 穩定性邊界的尚未解答的問題。