LWN：移除 CONFIG_ANDROID！

關注了就能看到更多這么棒的文章哦～

The end of CONFIG_ANDROID

By Jonathan Corbet
July 4, 2022
DeepL assisted translation
https://lwn.net/Articles/899743/

內(nèi)核有數(shù)千個 config 選項，其中許多選項在以微妙或令人驚訝的方式改變內(nèi)核的行為。在這些選項中，CONFIG_ANDROID 是一個相對簡單的選項，它的完整描述是 "啟用對安卓平臺所需的各種驅(qū)動的支持"。事實證明，這個選項的作用不止于此，這一點令一些用戶感到驚訝。這引出了一個刪除該選項的計劃，但這個計劃也引入了一兩個意外，以及一些分歧。

討論開始于 Alex Xu 報告了一個 RCU（read-copy-update）的 error，這個 error 在他的系統(tǒng)從 suspend 狀態(tài)恢復后會出現(xiàn)。此后不久，Xu 意識到這個問題與他的內(nèi)核在構建時啟用了 CONFIG_ANDROID 這個改動有關；該選項的眾多影響之中，它也會大大減少 RCU 開始發(fā)出 stall warning 的時間閾值。RCU 的維護者 Paul McKenney 在這件事被報出來之后看起來不太同情：

讓我們面對現(xiàn)實吧，CONFIG_ANDROID=y 的意圖和目的是非常直截了當和明確無誤的。因此，也許不運行安卓設備但又想獲得一點安卓功能的人應該采取其他做法，而不是在他們的 .config 文件中直接設置 CONFIG_ANDROID=y。對我來說，我意外的是它怎么花了這么長時間才讓你受害。

這個回答來自討論的一部分，沒有直接出現(xiàn)在 archives 中，但可以在 Xu 的回答中看到他引用了這一點，他指出 Debian 和 Fedora 的內(nèi)核都啟用了 CONFIG_ANDROID，因為這是要讓 binder module 能工作的唯一方法。Xu 認為，這個選項的意圖并不像人們想象的那樣 "直截了當和明確無誤"；這么簡單的一行描述中也沒有提到改變內(nèi)部 RCU timeout 值。"如果主要的發(fā)行版供應商一直在犯這個'錯誤'，那么也許問題不是出在他們身上"。

Christoph Hellwig 很快就提出了一個 patch，將 CONFIG_ANDROID 完全刪除，稱其為 "顯然是個壞主意"。Greg Kroah-Hartman 同樣迅速同意，并將該 patch 排到了下一個合并窗口。沒有人反對，直到 Jason Donenfeld 指出，這個 config 還有其他令人意外的影響，刪除它可能會在 Android 系統(tǒng)上產(chǎn)生問題。

具體來說，隨機數(shù)生成器（random-number generator）以及 WireGuard VPN tunnel 的實現(xiàn)都會因系統(tǒng) suspend 而采取一些措施。隨機數(shù)發(fā)生器將在系統(tǒng) resume 后重新獲取隨機數(shù)種子，而 WireGuard 將在 suspend 前清除其 key 相關的數(shù)據(jù)。這兩個動作都是為了提高安全性，但由于電源管理的處理方式，它們在安卓系統(tǒng)上可能會出現(xiàn)問題。運行安卓系統(tǒng)的設備是盡量傾向于多睡眠的；它們會找任何機會來進入睡眠狀態(tài)，以節(jié)省電力。經(jīng)常重置隨機數(shù)發(fā)生器可能會比較低效，而經(jīng)常清除 WireGuard key 可能會完全破壞通信。為了避免這些問題，如果內(nèi)核是用 CONFIG_ANDROID 構建的，就不會進行這些舉動。

去掉 CONFIG_ANDROID 也就去掉了這種特殊的行為；Donenfeld 擔心，這樣的變動可能會在未來造成 regression。他要求 Hellwig 保證不會產(chǎn)生這些問題，或者提供一個 fix 這些問題的 patch 作為新版本。隨后，雙方就誰有責任修復潛在問題、CONFIG_ANDROID 的使用是否正確、刪除是否構成用戶空間 ABI 的 regression 等問題進行了不太愉快的討論。

最終，Kroah-Hartman 表示同意 Hellwig 的觀點。他說，安卓設備遇到的任何問題，在打了 patch 的內(nèi)核真正被用到這類設備上時，早就被發(fā)現(xiàn)和修復了，但現(xiàn)在的改動可能會修復與 desktop 有關的問題。因此，這一變動似乎很快會合入 mainline 了。

爭論的核心是使用 CONFIG_ANDROID 作為系統(tǒng)會要頻繁 suspend 和 resume 的指標這一點。但是，正如已經(jīng)看到的，有許多啟用了 CONFIG_ANDROID 的系統(tǒng)并沒有表現(xiàn)出這種行為，但無論如何都會采用了相應的行為。也可能有一些系統(tǒng)經(jīng)常 suspend，本應該采用這種行為，但它們沒有運行 Android，也沒有啟用 CONFIG_ANDROID。大家的共識似乎是，使用 CONFIG_ANDROID 來調(diào)節(jié) RCU stall timeout 或加密軟件對于電源管理事件的響應動作，這是一個需要 fix 的 bug。

所以，能讓隨機數(shù)和 WireGuard 滿意，需要用一些其他的方式來表明系統(tǒng)會經(jīng)常掛起。有人談論過采用一個新的配置選項或者一個可以從用戶空間寫入的 sysfs knob，這就可以允許在運行時來改變行為了。編者建議內(nèi)核可以觀察實際的 suspend 行為并自己來選擇正確的行為，這個建議很快就被駁回了。

現(xiàn)在看來，要做的其實是增加一個新的配置選項，叫做 CONFIG_PM_USERSPACE_AUTOSLEEP，這個選項會讓內(nèi)核針對一個頻繁 suspend 的系統(tǒng)來進行準備，并啟用了（以前）Android 的專用行為。這個選項有一個更詳細的 help 信息，描述了它的實際作用，并警告說它 "不應該僅僅為了好玩而啟用"。相關的安卓所必需的改動已經(jīng)被創(chuàng)建，這似乎是一個每個人都滿意的解決方案。

不過，這個解決方案的產(chǎn)生方式本可以更好。當開發(fā)者為了一個共同的目標而合作，而不是爭論誰做得不對的時候，內(nèi)核社區(qū)的工作效果最好。最終確實走向了這樣的情況，但是花了不少時間才達到這個效果。多位開發(fā)者賦予 CONFIG_ANDROID 一些令人困惑的含義，因此需要好多人才能把它弄清楚就不那么奇怪了。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關注，關注 LWN 深度文章以及開源社區(qū)的各種新近言論～