將一個平台標記為過時，只是 Kconfig 中的一行設定。真正動手處理它留下的數千行交錯驅動程式碼，完全是另一回事——這種落差如今正困擾著 Linux 核心長年清理老舊 32 位元 ARM 硬體支援的工程。
據 Phoronix 本月報導，資深 ARM Linux 維護者 Arnd Bergmann 過去近一年來一直在處理一項規模不小的修剪工作：從主線核心樹中移除舊的 ARM 平台。正式層面的成果在 Linux 7.3 週期落地，多個較舊的 32 位元 ARM 平台在該版本被正式棄用。實際層面的工作才剛剛開始。棄用這些平台讓數百個核心驅動程式變得孤兒化，而實際移除這段無用碼本身就構成挑戰——因為殘留程式碼與樹中其他部分的交錯程度遠超預期。
棄用與刪除之間的差異正是故事的核心。Kconfig 棄用警告使用者與下游打包者，某個平台已經時日無多；它不改變任何程式碼，也不會移除任何二進位檔。驅動程式繼續編譯、缺陷繼續針對它們被回報——而在某些發行版中，它們也繼續隨版本出貨。Bergmann 後續的清理工作需要梳理平台與仍活躍目標共享的程式碼、整合多年來累積的增量式 patch，同時確保任何真正仍在舊版裝置上運行的系統不會被破壞。
對於管理使用壽命長的 32 位元 ARM 裝置組合的營運者而言——這類組合涵蓋大量工業、網路與嵌入式裝置——這個發展帶來的是早期警示，而非立即警報。這類部署所用的硬體往往依循十年或更長的更新周期，而目前進行的清理是全球性的主線核心流程，而非針對任何特定市場的信號。但發展方向是清楚的：看似低風險的選項其實是代價最高的一個。在 out-of-tree patch 樹或無人維護的分支上繼續承載陳舊的核心程式碼，表面上成本為零——直到它所依賴的平台被主線剔除，而這個缺口必須在短時間內補上，由那些可能多年未碰過相關程式碼的團隊來完成。
這也提醒了我們這個廣泛使用的上游專案背後的維護現實：無用程式碼並非免費攜帶，而清除它的成本早在使用者察覺任何變化之前，就由少數維護者承擔。
任何持有 ARM32 裝置組合的人都應將此事視為一個提示而非結論：現在就盤點你的 ARM32 裝置組合，並確認你在生產環境中運行的各個裝置，其上游狀態是否仍受正式支援——抑或只是被棄用而已。
將一個平台標記為過時，只是 Kconfig 中的一行設定。真正動手處理它留下的數千行交錯驅動程式碼，完全是另一回事——這種落差如今正困擾著 Linux 核心長年清理老舊 32 位元 ARM 硬體支援的工程。
據 Phoronix 本月報導，資深 ARM Linux 維護者 Arnd Bergmann 過去近一年來一直在處理一項規模不小的修剪工作：從主線核心樹中移除舊的 ARM 平台。正式層面的成果在 Linux 7.3 週期落地，多個較舊的 32 位元 ARM 平台在該版本被正式棄用。實際層面的工作才剛剛開始。棄用這些平台讓數百個核心驅動程式變得孤兒化，而實際移除這段無用碼本身就構成挑戰——因為殘留程式碼與樹中其他部分的交錯程度遠超預期。
棄用與刪除之間的差異正是故事的核心。Kconfig 棄用警告使用者與下游打包者，某個平台已經時日無多；它不改變任何程式碼，也不會移除任何二進位檔。驅動程式繼續編譯、缺陷繼續針對它們被回報——而在某些發行版中，它們也繼續隨版本出貨。Bergmann 後續的清理工作需要梳理平台與仍活躍目標共享的程式碼、整合多年來累積的增量式 patch，同時確保任何真正仍在舊版裝置上運行的系統不會被破壞。
對於管理使用壽命長的 32 位元 ARM 裝置組合的營運者而言——這類組合涵蓋大量工業、網路與嵌入式裝置——這個發展帶來的是早期警示，而非立即警報。這類部署所用的硬體往往依循十年或更長的更新周期，而目前進行的清理是全球性的主線核心流程，而非針對任何特定市場的信號。但發展方向是清楚的：看似低風險的選項其實是代價最高的一個。在 out-of-tree patch 樹或無人維護的分支上繼續承載陳舊的核心程式碼，表面上成本為零——直到它所依賴的平台被主線剔除，而這個缺口必須在短時間內補上，由那些可能多年未碰過相關程式碼的團隊來完成。
這也提醒了我們這個廣泛使用的上游專案背後的維護現實：無用程式碼並非免費攜帶，而清除它的成本早在使用者察覺任何變化之前，就由少數維護者承擔。
任何持有 ARM32 裝置組合的人都應將此事視為一個提示而非結論：現在就盤點你的 ARM32 裝置組合，並確認你在生產環境中運行的各個裝置，其上游狀態是否仍受正式支援——抑或只是被棄用而已。