LWN：關(guān)于module、GKI、以及火箭科學(xué)！
關(guān)注了就能看到更多這么棒的文章哦～
The intersection of modules, GKI, and rocket science
By Jonathan Corbet
October 11, 2021
DeepL assisted translation
https://lwn.net/Articles/872209/
人們通常不認(rèn)為那些圍繞著對(duì)跟特定平臺(tái)有關(guān)的 configuration 和 driver 進(jìn)行修改的 patch series 會(huì)有多少爭(zhēng)議。因此，近期看到三星 Exynos 平臺(tái)上的一些工作引發(fā)的憤怒討論就很令人驚訝了。當(dāng)我們深入研究這個(gè)討論時(shí)，就會(huì)意識(shí)到，這里主要是與硬件供應(yīng)商與內(nèi)核開發(fā)社區(qū)合作的最佳方式有關(guān)。
9 月中旬，Will McVicker 發(fā)布了一系列針對(duì) Exynos config 文件的簡(jiǎn)單修改。一周后，提供了一個(gè)更新版本，不過改動(dòng)非常多。這兩次的目的都是為了修改一些芯片（SoC）的底層驅(qū)動(dòng)程序，使它們能夠被構(gòu)建為 loadable module。這似乎是一個(gè)沒有多少爭(zhēng)議的改動(dòng)。通常情況下，人們都期望設(shè)備驅(qū)動(dòng)程序應(yīng)該是可以編譯為 module 的。但對(duì)于這些底層 SoC 驅(qū)動(dòng)程序來說，情況有些不同。
Generic kernels and essential drivers
在很久以前，基于 Arm 的 SoC 的內(nèi)核都是針對(duì)某個(gè)特定目標(biāo)平臺(tái)編譯的。x86 內(nèi)核通常可以在所有 x86 處理器上運(yùn)行，而 Arm 內(nèi)核卻是為很小范圍的目標(biāo)平臺(tái)建立的，無法在其他平臺(tái)上啟動(dòng)。多年來，Arm 開發(fā)者努力使 64 位 Arm 內(nèi)核具有足夠的通用性，這樣每一個(gè)二進(jìn)制鏡像文件就可以在各種平臺(tái)上能正常啟動(dòng)了。在很大程度上，這種可移植性（portability）是通過將驅(qū)動(dòng)程序構(gòu)建為 module 來實(shí)現(xiàn)的，這樣處理之后要在特定設(shè)備上運(yùn)行內(nèi)核就只需要加載與該設(shè)備相關(guān)的驅(qū)動(dòng)程序就好。
不過，還有一個(gè) bootstrapping 問題需要解決；在內(nèi)核能夠加載一個(gè) module 之前，它必須能夠先讓這個(gè)平臺(tái)啟動(dòng)到一個(gè)已知的穩(wěn)定狀態(tài)，并且能夠 mount 一個(gè)基于 RAM 的 root 文件系統(tǒng)。只有當(dāng)啟動(dòng)時(shí)所需的驅(qū)動(dòng)程序被 built-in 到內(nèi)核本身的情況下才能達(dá)到這個(gè)目標(biāo)。因此，通用內(nèi)核（generic kernel）就包含了許多個(gè)平臺(tái)特有的驅(qū)動(dòng)程序，用于配置 clock、pin controller 等。如果沒有它們的話內(nèi)核就無法完成啟動(dòng)。長期以來，維護(hù)者的政策都規(guī)定，任何對(duì)啟動(dòng)過程至關(guān)重要的驅(qū)動(dòng)都必須編譯到內(nèi)核里面。
McVicker 的 patch set 把許多這類重要的驅(qū)動(dòng)程序（原因下面要詳細(xì)介紹）從內(nèi)核鏡像中移除，使其成為了 loadable module。表面上看，這種改動(dòng)并不違反這些驅(qū)動(dòng)的 policy，但必須要先證明這些驅(qū)動(dòng)實(shí)際上不是內(nèi)核要在相關(guān)硬件平臺(tái)上能啟動(dòng)的必要條件。這就是這組 patch set 的第一個(gè)大問題，McVicker 在說明郵件中明確表示，這些改動(dòng)實(shí)際上沒有在相應(yīng)的硬件上進(jìn)行測(cè)試。雖然他很樂觀地認(rèn)為這些系統(tǒng)應(yīng)該仍然可以 module 方式的驅(qū)動(dòng)來啟動(dòng)，但還沒有人來證實(shí)這一點(diǎn)。
在內(nèi)核社區(qū)，僅靠這種樂觀的態(tài)度是無法說服別人的。由于缺乏測(cè)試，Exynos 平臺(tái)維護(hù)者 Krzysztof Kozlowski 多次拒絕這些 patch。在他確定所有 Exynos 系統(tǒng)都可以用這些 module 方式的驅(qū)動(dòng)正常啟動(dòng)之前，他不愿意接受這些改動(dòng)。他已經(jīng)提出愿意幫助來進(jìn)行一些必要的測(cè)試。同時(shí)，Arnd Bergmann 也支持 Kozlowski 的沉默態(tài)度：
"正確性第一" 的原則是沒有商量余地的。如果對(duì)代碼或測(cè)試的內(nèi)容感到不滿意，因?yàn)槟阏J(rèn)為它破壞了一些東西，那就應(yīng)該拒絕這些 patch。把核心的 platform 功能移除出去本質(zhì)上就是很難的，可能會(huì)在各種所有地方各種可能出錯(cuò)，比如過去有可能是因?yàn)楣潭ǖ膯?dòng)順序而碰巧能正常工作。
缺乏測(cè)試似乎是可以解決的問題。不過，要讓測(cè)試結(jié)果達(dá)到讓大家有信心的水平可能還需要一段時(shí)間。比如說一些在運(yùn)行某些特定 SoC 的系統(tǒng)可能可以在沒有某些 clock driver 的情況下啟動(dòng)，這是因?yàn)?firmware 在開機(jī)時(shí)就將時(shí)鐘初始化為正確的值了。不過，指望所有的 firmware 都會(huì)做這件事的話，可能有點(diǎn)天真了。無論如何這類測(cè)試都應(yīng)該在提交 patch 之前就完成，應(yīng)該也要在事后補(bǔ)上。
Out-of-tree code
還有一個(gè)問題是為什么要做這種可能有風(fēng)險(xiǎn)的改動(dòng)。顯而易見的一個(gè)好處是使 core kernel image 能更小。這在所有不使用相關(guān)驅(qū)動(dòng)的平臺(tái)上尤其是件好事，因?yàn)樗鼈兤鋵?shí)是沒用的代碼。但是，這里還有另一個(gè)動(dòng)機(jī)，是來自另一個(gè)名字中也帶 generic 的內(nèi)核版本有關(guān)。
大家都知道安卓設(shè)備的內(nèi)核包含了大量的樹外（out-of-tree）代碼，這些代碼有時(shí)都比設(shè)備上正在使用的 mainline 代碼更加重要（outweighs）了。這導(dǎo)致了整個(gè)生態(tài)系統(tǒng)出現(xiàn)問題，比如缺乏與上游內(nèi)核開發(fā)者的合作、Android kernel space 的碎片化、當(dāng)供應(yīng)商停止（總有這一天）進(jìn)行安全更新時(shí)就無法再得到更新、以及維護(hù)所有這些內(nèi)核帶來的額外成本。為了解決這個(gè)問題，谷歌一直在推動(dòng)基于安卓的設(shè)備供應(yīng)商來配合它的 "通用內(nèi)核鏡像（generic kernel image）"（GKI）進(jìn)行開發(fā)，這是一個(gè)所有安卓設(shè)備都必須提供的 core kernel。供應(yīng)商需要提供他們自己的 module 來加載到該內(nèi)核中，但他們不能取代內(nèi)核本身。
這個(gè)規(guī)則帶來了一些好處。供應(yīng)商的改動(dòng)被限制在那些可以用 module API 來實(shí)現(xiàn)的功能之內(nèi)，而谷歌也一直在推動(dòng)對(duì)這些改動(dòng)的限制。供應(yīng)商替換掉 CPU scheduler 的日子現(xiàn)在就應(yīng)該結(jié)束了。供應(yīng)商自然對(duì)這些限制感到不滿，但他們除了遵從之外沒有什么其他選擇。如果他們選擇來運(yùn)行自己的系統(tǒng)，也就是事實(shí)上是一個(gè)從安卓 fork 出來的系統(tǒng)，那么他們就會(huì)失去使用許多谷歌應(yīng)用和服務(wù)權(quán)利，而這些應(yīng)用和服務(wù)正是安卓對(duì)他們客戶的價(jià)值。
因此，GKI 內(nèi)核中的代碼不能被 device vendor 修改。相應(yīng)地，從 module 中加載的代碼可以被拿掉或者替換掉。從這個(gè)角度來看，將內(nèi)置驅(qū)動(dòng)程序改成 module 的愿望就很容易理解了。即便如此，這種情況也還有兩個(gè)方面值得研究。其一是供應(yīng)商希望在他們的設(shè)備上能運(yùn)行 out-of-tree module，而不是將他們的驅(qū)動(dòng)程序推倒 upstream，這樣就能對(duì)競(jìng)爭(zhēng)對(duì)手來隱藏他們自己特有的一些做法。正如 Lee Jones 所描述的：
為了讓供應(yīng)商與 upstream 能更緊密地合作，他們希望在設(shè)備發(fā)布之前要有能力來替換掉?少數(shù)?的驅(qū)動(dòng)程序，從而來添加一些他們認(rèn)為能夠?yàn)樗麄兲峁└?jìng)爭(zhēng)優(yōu)勢(shì)的功能（大家之前稱這為 "value-add"）。這是一個(gè)無法繞過的要求。
可以想象，這一立場(chǎng)在許多內(nèi)核開發(fā)社區(qū)中被認(rèn)為是無法接受的。它也確實(shí)不完全令人信服，正如 Tomasz Figa 所說：
一般來說，這里提到的子系統(tǒng)都是非?；镜模╟lock、pinctrl、rtc），我真的無法想象人們會(huì)因?yàn)楦?jìng)爭(zhēng)的原因而在這里隱藏什么樣的火箭科學(xué)尖端科技。
Jones 后來不再強(qiáng)調(diào)這個(gè)討論點(diǎn)，但有點(diǎn)晚了。他已經(jīng)大聲說出了之前人們避免提及的部分內(nèi)容。
另一個(gè)問題則更簡(jiǎn)單易懂。即使一組 clock driver 不包含競(jìng)爭(zhēng)對(duì)手會(huì)感興趣的什么秘密，供應(yīng)商可能只是缺乏努力把驅(qū)動(dòng)推倒 upstream 的意愿。雖然有可能將 out-of-tree 的驅(qū)動(dòng)程序內(nèi)置到 GKI 中，但谷歌顯然不想再繼續(xù)背負(fù)這些負(fù)擔(dān)，所以他會(huì)一直感到將驅(qū)動(dòng)程序放入 mainline 的壓力。如果驅(qū)動(dòng)可以直接由供應(yīng)商作為 module 提供，那么它們就可以從 GKI 中拿出去了，這種壓力也就消失了。關(guān)于 Exynos 的改動(dòng)，估計(jì)合理的解釋還是缺乏推向 upstream 的動(dòng)力。正如 Kozlowski 在上述鏈接的郵件中指出的那樣，自 2017 年以來，三星只對(duì) Exynos 子系統(tǒng)做出過一次改動(dòng)。
Jones 曾試圖將供應(yīng)商在 upstream 動(dòng)力方面的問題定義為暫時(shí)性的問題，他說："供應(yīng)商不可能馬上就將所有功能都上傳到 upstream"。但后來，他說：
但是 [他們] 沒有動(dòng)力給 upstream 推送那些無法[為]他們繼續(xù)賺錢的舊（死）平臺(tái)的代碼。我們?cè)谶@里談?wù)摰牟皇且粋€(gè)心地善良的個(gè)人，而是一些商業(yè)實(shí)體。
如果新的或舊的代碼都不能被推到 upstream，那么對(duì)這些平臺(tái)的 mainline 支持似乎就陷入了死胡同了。
Better or worse?
許多內(nèi)核開發(fā)者的自然反應(yīng)都是想讓那些似乎正在尋找方法避免與開發(fā)社區(qū)接觸的供應(yīng)商的日子變得更難過。這就包括拒絕這里正在討論的 patch set。Olof Johansson 的意見是：
這個(gè) patch set 不應(yīng)該被采納。
GKI 是一項(xiàng)了不起的努力，因?yàn)樗雌饋硐窆雀杞K于有骨氣向供應(yīng)商施加壓力，讓他們把所有的東西放到 upstream 去。
這個(gè) patch set 通過打開一個(gè)像卡車那么大的漏洞，來稀釋和破壞了所有這些努力、減少了 GKI 的影響，并從整體上消除了讓供應(yīng)商們做正確事情的動(dòng)力。
相反，McVicker 認(rèn)為，將這些驅(qū)動(dòng)程序改為 module 是一種使供應(yīng)商能更加參與到 upstream 的方式，并將改善整體情況：
我們相信，如果我們讓 SoC 廠商在項(xiàng)目啟動(dòng)和開發(fā)階段更容易直接使用 upstream 內(nèi)核，那么這將減少與上游合作的陣痛（因?yàn)闀?huì)有更少的 downstream 改動(dòng)了）并增加對(duì) upstream 的貢獻(xiàn)。
很難說哪一種觀點(diǎn)更接近事實(shí)。每一種立場(chǎng)可能都有一些廠商是屬于這種情況、而對(duì)另一些廠商來說則是錯(cuò)誤的。讓供應(yīng)商與 upstream 接觸是一個(gè)持續(xù)進(jìn)行的過程，需要明智地使用胡蘿卜和大棒。
具體到這一次討論，結(jié)果并不存在很大的疑問。讓不配合的供應(yīng)商能生活得更輕松，這通常本身并不是足以將 patch set 從內(nèi)核中剔除的理由。在上面討論信息很好地描述了這一點(diǎn)：
我理解對(duì)于 SoC 廠商來說，如果永遠(yuǎn)不必再把他們平臺(tái)的代碼上傳到 upstream，那確實(shí)是很方便的，而且 Android 在短期內(nèi)也會(huì)從中受益。
從我 upstream 的角度來看，這絕對(duì)不可以成為一個(gè)目標(biāo)。如果將內(nèi)核變得更加容易使用 module，那這個(gè)副作用還是不錯(cuò)的。
所以，從某種意義上說，許多討論都是無關(guān)緊要的。如果這些 patch 能夠被證明是可以正常工作的（目前這一點(diǎn)還沒有完成驗(yàn)證），那么它們就與社區(qū)的眾多長期目標(biāo)是一致的，可能遲早會(huì)進(jìn)入 mainline。不過關(guān)于這會(huì)鼓勵(lì)供應(yīng)商盡量在 upstream 工作還是正相反（使他們更傾向于遠(yuǎn)離 upstream），這還有待觀察。但是，與不配合的供應(yīng)商相關(guān)的問題已經(jīng)存在了很長時(shí)間，無論如何這些問題今后也都會(huì)不斷出現(xiàn)。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～