LWN：滾動(dòng)發(fā)布的穩(wěn)定版內(nèi)核！

關(guān)注了就能看到更多這么棒的文章哦～

Rolling stable kernels

By Jake Edge
October 6, 2021
OSSNA
DeepL assisted translation
https://lwn.net/Articles/871989/

Sasha Levin 是 stable kernel 維護(hù)者之一，2021 年北美開源峰會(huì)上他發(fā)表了一個(gè)對(duì) stable
tree 采用新的方式來處理的建議。他指出，在內(nèi)核的絕大多數(shù)歷史中，版本號(hào)都沒那么重要，但版本號(hào)的命名規(guī)則給人們的印象是它們是有意義的，這就導(dǎo)致了人們對(duì)內(nèi)核的看法與其實(shí)際維護(hù)方式之間產(chǎn)生了脫節(jié)。他建議制作一個(gè) "rolling stable" release，來給用戶提供他們真正所需要的東西，也就是及時(shí)地 fix 他們的內(nèi)核中的問題，而不用強(qiáng)迫他們選擇切換到新的一個(gè)版本號(hào)代表的版本。

Context

他首先介紹了內(nèi)核版本命名規(guī)范（kernel versioning scheme）的歷史，以及這些年來它們是如何演變的。從 0.01 版本開始，Linus Torvalds 就使用了一個(gè)在小型項(xiàng)目中經(jīng)常采用的很常見的版本號(hào)機(jī)制：如果只有一些小的新增功能，就只把版本號(hào)提高一點(diǎn)點(diǎn)；而如果有更大的功能或更多的功能加入進(jìn)來，就多提高一些。當(dāng) Torvalds 認(rèn)為他開發(fā)出來的東西已經(jīng)足夠讓人們廣泛使用時(shí)，他就發(fā)布了 Linux 1.0。

[Sasha Levin]

在 1.0 版本發(fā)布之后，Linux 有了更多的用戶。這些用戶不一定都是內(nèi)核開發(fā)者。他們可能是想開發(fā)一些應(yīng)用程序，來運(yùn)行他們自己的工作任務(wù)（workload）。他們不想使用開發(fā)中的版本的內(nèi)核，于是提出了 stable kernel 這個(gè)想法。內(nèi)核于是就采取了這樣的模式，用一個(gè) branch 來維護(hù) stable kernel，另一個(gè)分支則用來進(jìn)行活躍的開發(fā)。

Bug Fix 會(huì)從 development branch 來 backport 到 stable branch 上。等 development branch 準(zhǔn)備好可以進(jìn)行發(fā)布了，那么它就會(huì)成為下一個(gè) stable branch。內(nèi)核繼續(xù)沿用了之前的做法，也就是在增加了新的功能（feature）的時(shí)候來增大版本號(hào)，但由于缺乏集中管理，因此總是不確定什么時(shí)候可以發(fā)布新版本。Levin 指出，在 2.0 版本到 2.6 版本內(nèi)核之間的那段時(shí)間，這個(gè)過程看起來總是停滯不前的狀態(tài)。

從 2.4 到 2.6 的過程則是 "一次花了三年時(shí)間的不斷探索"。他說，這下社區(qū)就認(rèn)識(shí)到這個(gè)流程是行不通的，最終會(huì)導(dǎo)致 "總是需要不確定的甚至無限長的時(shí)間才能進(jìn)入下一版本"。因此，在內(nèi)核 2.6 時(shí)代，內(nèi)核開發(fā)者想出了一個(gè)新的方法，他們不再基于 feature 來發(fā)布新版本，而是改為基于時(shí)間點(diǎn)進(jìn)行發(fā)布的流程。

最終，演化出來的做法變?yōu)榱耍好?10 周左右的時(shí)間發(fā)布一次新的 kernel。而內(nèi)核開發(fā)者也開始宣傳說版本號(hào)并不代表什么了，而且確實(shí)它們也沒那么重要了。但這是一個(gè)典型的 "engineering doing marketing （工程師做營銷）" 的例子，Levin 認(rèn)為，因?yàn)榘姹咎?hào)的命名規(guī)范并沒有隨著改動(dòng)，同時(shí)也沒有將版本號(hào)不再代表什么的這個(gè)觀點(diǎn)明確地傳達(dá)給客戶。

這就導(dǎo)致了現(xiàn)在熟悉的工作流程，也就是兩周的合并窗口、接下來是七八個(gè) release candidates，然后得出一個(gè)正式版本。每個(gè)內(nèi)核都被人們認(rèn)為是穩(wěn)定的，所以不再有單獨(dú)的 development kernel 分支了。他說，有一些客戶想要達(dá)到更高的穩(wěn)定性，這就是長期穩(wěn)定版本（LTS）的想法來源了。這種工作模式運(yùn)行得很好，于是內(nèi)核在 2.6.x 系列上保持了大約 8 年時(shí)間。

Expectations

但在轉(zhuǎn)向新的這種 time-based 開發(fā)流程中也犯了一些錯(cuò)誤。雖然內(nèi)核開發(fā)人員不再注重版本號(hào)，但客戶這邊并沒有忽視它，而且社區(qū)也沒有很好地推廣宣傳這個(gè) time-based version 的想法。由于版本號(hào)數(shù)字仍然存在，客戶總是認(rèn)為它們是有含義的，所以在他們看來，從 3.20 到 4.0 的版本號(hào)轉(zhuǎn)變是 "big and scary，非常大的可怕改動(dòng)"，因?yàn)樗麄兛吹街靼姹咎?hào)已經(jīng)改變了。

在 2.6.x 上停留了這么久也帶來了一些影響。當(dāng)時(shí)這么做的原因中一部分是為了幫助客戶適應(yīng)新系統(tǒng)，但在某種程度上來說讓他們過得太舒服了。當(dāng)內(nèi)核開發(fā)者想要遷移到 3.0 時(shí)，他們發(fā)現(xiàn)一些產(chǎn)品中已經(jīng)嵌入了一些關(guān)于內(nèi)核版本號(hào)的各種各樣的假設(shè)，所以當(dāng)時(shí)開發(fā)者們不得不增加一些變通方法來繞過。

Levin 說，客戶已經(jīng)習(xí)慣了小版本的更新（例如從 2.6.y 到 2.6.y+1），但是他們也開始對(duì)版本號(hào)的含義做出了很多猜想性地判定。比如一旦 minor number 已經(jīng)非常大了，他們就會(huì)把這個(gè)版本它當(dāng)作一個(gè) "more minor，更加不重要" 的版本變化。在他們眼里，2.6.1 到 2.6.2 是一個(gè)重要的改動(dòng)，需要立即升級(jí)，但 2.6.30 到 2.6.31 的改動(dòng)則不那么重要，可以推遲到 2.6.35 或其他時(shí)候來升級(jí)。而事實(shí)上對(duì)于內(nèi)核社區(qū)來說，這兩種情況根本沒有什么區(qū)別。

為了要解決這個(gè)問題，大家計(jì)劃轉(zhuǎn)向 3.0，并在每次發(fā)布時(shí)都對(duì)第二個(gè)數(shù)字（次要版本）進(jìn)行增長，也就事實(shí)上放棄了在 mainline 發(fā)布時(shí)使用版本號(hào)中的第三個(gè)數(shù)字。Levin 稱這是 "finger and toes" 方式的版本號(hào)命名方式，因?yàn)?Torvalds 說他一般也就愿意數(shù)到大約 20 個(gè) "minor" 版本，然后就不愿意繼續(xù)數(shù)數(shù)了，而需要開始增加主版本號(hào)（major version number）。所以在 3.19 之后，人們發(fā)布了 4.0。

他說，對(duì)于內(nèi)核開發(fā)人員來說，版本號(hào)除了用來衡量在時(shí)間線上所處的位置之外，仍然是沒有任何其他意義的。用戶應(yīng)該要運(yùn)行最新的版本。但是，如果你告訴客戶他們需要從 3.20 升級(jí)到 4.0，他們會(huì)認(rèn)為這是一項(xiàng)需要仔細(xì)規(guī)劃以及書面申請(qǐng)的持續(xù)多年的一個(gè)工作，"所以他們只會(huì)在有時(shí)間的時(shí)候才去做這件事，事實(shí)上也就永遠(yuǎn)不會(huì)做了"。從 3.20 到 4.0 在他們看來是一個(gè)很大的變動(dòng)，而 4.0 到 4.2 的變動(dòng)則似乎要小得多，盡管后者加入的改動(dòng)數(shù)量大約是前者的兩倍。

隨著時(shí)間的推移，內(nèi)核社區(qū)在 testing、避免性能 regression、以及不破壞用戶空間等等方面已經(jīng)做得更好了，用戶應(yīng)該更容易遷移了。但是，用戶這邊仍然有不少阻力做這件事，部分原因就是內(nèi)核開發(fā)者還沒有向用戶講清楚并推廣內(nèi)核命名的這個(gè)規(guī)劃。

然而，一些發(fā)行版和一部分用戶已經(jīng)開始聽從了內(nèi)核開發(fā)者的意見，并且正在不斷跟上最新版的內(nèi)核或 LTS 版本。他們已經(jīng)認(rèn)識(shí)到這些版本只是基于時(shí)間來命名的，所以升級(jí)事實(shí)上并不可怕。除此之外，用戶是希望得到最新的那些亮眼功能（"BPF，新的 I/O scheduler，他們想要盡量提升性能"），而且他們想馬上就能得到所有這些優(yōu)勢(shì)，不希望把更多的新功能 backport 到舊版本內(nèi)核上。他們還希望能有頻繁的安全更新。所有這些都與內(nèi)核開發(fā)者的愿望相吻合，并且能夠?qū)崿F(xiàn)。

Enterprise kernel 現(xiàn)在不那么流行了，這里的一部分原因是 "維護(hù)某個(gè)古老的內(nèi)核的困難度已經(jīng)加倍增長"。內(nèi)核的發(fā)展如此之快，以至于有越來越多的 Backport 動(dòng)作需要做，每一個(gè)都會(huì)使得維護(hù) Enterprise kernel 變得更加復(fù)雜。實(shí)際上，大多數(shù)企業(yè)內(nèi)核已經(jīng)變成了 "frankenkernels"，它們帶有了當(dāng)前最新版本內(nèi)核大部分功能的 backport 代碼，因此它們聲稱的版本號(hào)根本就不準(zhǔn)確。

Rolling

在 "LTS world" （也就是采用了 LTS 的做法之后） 中，用戶會(huì)選擇一個(gè)內(nèi)核的 LTS 系列，比如 5.10.x，并不斷將他們的內(nèi)核升級(jí)到該系列的最新版本，直到不可能再升級(jí)為止。當(dāng)這種情況發(fā)生時(shí)，他們就會(huì)選擇一個(gè)新的 LTS 系列，切換到該系列，從那里繼續(xù)重復(fù)之前的做法。內(nèi)核開發(fā)者一直希望讓他們更早地轉(zhuǎn)換到新版本，也就是當(dāng)下一個(gè)版本出來時(shí)（在這種情況下，5.11.x），他們就應(yīng)該開始使用這個(gè)新的系列了。

但是，要進(jìn)行這種轉(zhuǎn)換的話就需要用戶專門的努力。他們也必須選擇一個(gè)時(shí)間來做，但是 "從來沒有一個(gè)好的時(shí)間點(diǎn)會(huì)是 '我們?cè)撘淖兾覀兊膬?nèi)核了'，尤其是這么頻繁的情況"。除此之外，在中途切換到一個(gè)新的內(nèi)核 Git branh 還會(huì)碰到一些技術(shù)上的障礙，比如可能會(huì)有一些 patch 需要被 forward-ported。

因此，Levin 問道："可以做些什么來改善這個(gè)過程？" 不管是主版本號(hào)、次版本號(hào)還是穩(wěn)定版本之間的改動(dòng)，內(nèi)核社區(qū)都提供了同樣的保證："確保它不會(huì)破壞用戶空間"。它可能會(huì)意外地導(dǎo)致用戶空間出現(xiàn)一些問題，但如果這種情況出現(xiàn)了，那么就會(huì)在 kernel 里面進(jìn)行 fix。不過，這些破壞可能發(fā)生在任何類型的升級(jí)上，沒有哪種類型的升級(jí)更容易、或更不容易發(fā)生意外破壞。"版本號(hào)仍然是，真的真的不重要"。

我們的想法是 "消除摩擦點(diǎn)，eliminate the friction point"，即客戶需要選擇切換到下一個(gè)系列。目前，穩(wěn)定版和 LTS tree 的每個(gè) mainline 版本都有一個(gè) branch，而事實(shí)上，每次 Torvalds 發(fā)布版本時(shí)，stable tree 都會(huì)進(jìn)行一次 fork。mainline Git tree 直接繼續(xù)往下走，直到下一個(gè)合并窗口開啟的時(shí)候，那些為下一個(gè)版本而準(zhǔn)備的 patch 就會(huì)被提交到 main branch 上。而對(duì)于 stable tree 來說則沒有一個(gè)相應(yīng)的機(jī)制。

stable 版本的維護(hù)者們希望開始進(jìn)行一個(gè)不一樣的做法，也就是使用戶在每次轉(zhuǎn)移到一個(gè)新系列時(shí)不需要切換 branch。它保證是與當(dāng)前的代碼 tree 質(zhì)量相同，并按相同的時(shí)間表來推進(jìn)。但是它默認(rèn)是向前滾動(dòng)的，就像 Torvalds 的 tree 一樣。

我們的想法是使用 "Git 的魔法" 來實(shí)現(xiàn)這一切。不再進(jìn)行 cherry pick 來挑選 patch。取而代之的是使用 "Git merge 的改動(dòng)版本"，這種方式保留了現(xiàn)有 stable tree 中的 SHA1 值。Git tag 也得以保留，而保留 SHA1 就意味著那些希望避免受到供應(yīng)鏈攻擊（supply-chain attacks）而想要進(jìn)行驗(yàn)證的人可以更容易地利用 SHA1 值進(jìn)行驗(yàn)證。bisection 二分 Git 操作仍然是有效，patch author 不會(huì)變動(dòng)，所以 Git blame 也仍然有效，等等等等。他說，stable tree 的維護(hù)者只是 "稍微進(jìn)行了一些 Git 操作，讓人覺得所有這些開發(fā)都發(fā)生在一個(gè)分支里"。這個(gè)改動(dòng)所變化的僅僅是 "我們向終端用戶展示 kernel tree 的方式"。

目前，用戶會(huì)工作在某一個(gè) stable branch 或某一個(gè)一個(gè) LTS branch 上，但在這種模式下，他們其實(shí)工作環(huán)境變成了 the stable or LTS branch。他們不是在隨機(jī)使用一些內(nèi)核版本，而是在使用內(nèi)核開發(fā)者推薦的擁有最佳體驗(yàn)的版本。由此，他們將獲得所有最新的功能、bug fix 以及 security update。

Concerns

當(dāng)然，他也從公司和用戶的反饋中聽到了一些對(duì)這種方法的擔(dān)憂。首先，在滾動(dòng)模式下，對(duì)測(cè)試的需求增加了，這個(gè)工作被推給了用戶。但他并不同意這種看法。目前用戶認(rèn)為如果他們從 x.y.50 到 x.y.51，他們不需要重新進(jìn)行很多測(cè)試，但事實(shí)并非如此。滾動(dòng)發(fā)布的情況下也是如此。只要內(nèi)核發(fā)生了改動(dòng)，就必須進(jìn)行測(cè)試。

另一個(gè)令人擔(dān)心的地方是，滾動(dòng)發(fā)布模型有效地 "隱藏了它內(nèi)部的合并窗口"。某一天，這個(gè) rolling stable tree 可能是在 5.7.15，而下一天可能就是在 5.8.1 了。在這個(gè) pull 合并中，有很多 patch 是來自 5.8 的合并窗口，這是一個(gè)很大的變動(dòng)。但他認(rèn)為這一切又都回到了測(cè)試這一點(diǎn)上。有可能合并窗口引入了很多錯(cuò)誤，但也有可能一個(gè) stable patch 也可能會(huì)引入很多錯(cuò)誤。

他說，原來的時(shí)間表仍舊保持不變。這些 rolling stable 和 LTS branch 只是當(dāng)前 stable tree 的衍生版本。新的模式并不要求用戶要按照一個(gè)新的計(jì)劃時(shí)間表來做事，新模式中僅僅是在用戶決定升級(jí)和做 Git pull 時(shí)提供給他們最新的內(nèi)核而已。

滾動(dòng)模式不是一個(gè)激進(jìn)的變革，也不是一個(gè)新想法。他說："如果你使用 Debian 的話，這一直是它的工作方式"。Debian testing kernel 或多或少相當(dāng)于 rolling stable branch。他相信滾動(dòng)發(fā)布模式會(huì)成功，因?yàn)橛幸恍┌l(fā)行版和設(shè)備已經(jīng)在某種形式上使用該模式了，"他們喜歡這種工作方式"。Levin 說，總的來說，這是一個(gè)嘗試，以解決過去在版本劃分方面所犯的一些錯(cuò)誤，以及讓用戶清楚穩(wěn)定版開發(fā)者希望用戶應(yīng)該如何使用。

這個(gè) rolling stable 和 rolling LTS branches 已經(jīng)存在了。截至本文撰寫時(shí)，rolling stable 是 5.14.9，而 rolling LTS 則是 5.10.70。如前所述，它們只是現(xiàn)有 stable 和 LTS branch 的衍生版本，其中沒有任何內(nèi)容是其他兩個(gè)分支中所沒有的。"如果你想遵循 Linux 內(nèi)核的開發(fā)理念，這些分支將使你變得超級(jí)容易"。

在回答某個(gè)問題時(shí)，Levin 說，從某個(gè) patch 在 mainline 上發(fā)布，到這個(gè)改動(dòng)在 rolling stable tree 上出現(xiàn)，還是需要一段時(shí)間。等 5.15 版本發(fā)布之后，他們會(huì)一直等到 5.16 合并窗口關(guān)閉后再把 5.15 的改動(dòng)納入進(jìn)來。

還有人問他 LTS 版本的未來是怎樣。他指出，LTS 的想法有些矛盾。一方面，穩(wěn)定版的維護(hù)者建議永遠(yuǎn)使用最新的 LTS，但另一方面，LTS 版本的支持期為五年。他個(gè)人希望 LTS 版本隨著時(shí)間的推移而消失，但他認(rèn)為這不會(huì)很快發(fā)生，因?yàn)闆]有足夠的測(cè)試和鑒定工作。不過，他預(yù)計(jì)在 20 年內(nèi)，將不會(huì)有 LTS 內(nèi)核。

[感謝 LWN 訂戶支持編者去西雅圖參加北美開源峰會(huì) Open Source Summit North America。]

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

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