內核測試的現狀

新的內核總是會定期發布出來，但是其實大家并不是十分了解內核是如何被深入測試的。那么這里可以提前告訴大家，內核主干有可能并沒有做過充分的測試，而穩定內核可能會更少。。。 So what is going on there? Is stable kernel really stable? 剛好今年9月在洛杉磯舉辦的《Linux Plumbers Conference》有一個BOF（birds of a feather）會議，Dhaval Ginal和Sasha Levin組織了一個關于內核測試的相關討論，讓我們一起去看看。

由于大部分BoF的參會人員來自各個主要的Linux發行商，所以Giani開場的時候提了一個問題：“大家對于穩定內核（stable kernels）都做過了多少測試呢？大家是不是都是僅僅測試自己發行的內核然后再從穩定內核中backport一些安全以及其他相關的修復呢？對于穩定內核的測試從來都是置之不理呢？“ 對于這個問題的答案么，他自己半開玩笑的建議：可以將測試留給了用戶。除了上面這個半開玩笑的建議以外，大多數人都一致認為：目前對于穩定內核，除了簡單的構建-啟動測試以外，幾乎很少有其他方面的測試。那么這個現象是如何造成的呢？

內核測試的困境

第一點：開發者很難知道該去選擇什么樣的上游內核（upstream kernel）來測試。linux-next tree和穩定內核以及內核主線（mainline）都是在不斷地變化著，要想做到穩定測試是一件很難的事情。但是大家又都一致同意，能在代碼發布出來之前，發現其中的BUG還是很有價值的，所以一些發行版的研發人員就嘗試測試-rc1的內核。這樣做的話，如果bug被發現，它們將在發布前就被修正，這樣看起來是不錯的，但是這樣需要非常多的時間和機器去做好這件事。另外，測試時使用的哪個版本的內核配置，也會使這個問題的復雜度翻倍。

第二點：內核測試消耗大量的人力物力。有人舉了一個生動的例子，紅帽（RedHat）需要花費一年的時間去穩定RHEL選定的內核版本。而粗略估計有300個工程師去做這個事情，這也就是意味著一個公司需要花費了300個人年去測試和穩固一個內核（譯者在此處還是要感謝一下REDHAT）。此外，在驅動程序中，通常驅動的自檢程序是應該由內核開發人員編寫，但將個人的測試變成可以更廣泛使用的東西需要很多時間和精力，而驅動的作者根本沒有時間去添加一個自檢程序，所以驅動大多數是沒有自檢程序的。在許多情況下，正是由于這個原因，導致代碼質量很差。因此，現有的大部分自檢程序可能都是在子系統中并已經做了很好測試，這些測試用例還能發現的大部分的錯誤主要發生在與開發者自己運行的硬件架構不同有關，比如ARM相關的錯誤就是這樣被發現的。

第三點：啟動測試（boot testing）占了上游內核測試的大頭，占據了開發者更多的精力，所以最新發布的內核肯定可以啟動起來的。擁有特殊硬件的人會測試他們的驅動，所以通過這一測試也可以發現大部分驅動的bug。像Ftrace、調度器和內存管理由于使用的很廣泛，所以他們的測試也比較充分。除了以上這些組件以外，內核中其他的一些非核心或者不是被普遍使用的功能就可能沒有那么多的功能測試了。

第四點：內核測試門檻較高，如環境設備和知識儲備。對于一些想要測試驅動程序的人來說，他可能沒法獲得相應的硬件，即使有硬件，他還需要深入了解設備是如何工作的。理想情況下，驅動程序的作者應該測試這些設備，而大部分情況下也確實是這樣。不過這個解決方案仍然不是完美的。

第五點：測試覆蓋不全面，測試方面單一。因為雖然驅動作者試圖確保在他的測試用例下驅動程序是正確工作的，但是他們有著不同的動機，如果他被雇傭做這個事情那么可能測試會比較全面，而如果他僅僅是為了讓他自己的硬件可以正常工作，那么可能測試不會太全面，同時相應的文檔也基本沒有。

第六點：需要制定測試指南和幫助文檔。例如，在內核測試中我們還需要發現一些可能引入的性能退化（performance regressions），但是如果僅僅是做一些”隨機性能測試“（random performance testing），這是很難發現性能退化的，因此我們需要制定一些性能測試指南，以便可以進行一些蘋果對蘋果（apples-to-apples，譯為同類型的比較）的對比測試。再如，就像Mel Gorman的MMTests作為“kbench”這一性能測試套件的基礎，貌似有些與會者對這個測試套件不熟悉，所以MMTests需要有更好的文檔來幫助使用者去了解它。

第七點：進行內核測試的另一個困難是要內核配置的數量非常龐大。當穩定的內核被發布的時候，它可能有100個補丁，但任何測試套件都不可能執行許多次去測試這些補丁，那么測試穩定版本的意義到底是什么呢？

總結一下，在所有的這些測試工作中，最大問題就是資源，我們需要更多的人和更多的機器，從而可以更早地發現和修復錯誤。

企業是如何做的

我們再把話題切回到穩定內核。如果我們可以阻止所有可能的bug引入到內核，那么主線內核（mainline）無疑是完美的，我們也就不需要什么穩定分支了（stable trees）。當然現實是殘酷的，完美也是不可能的，所以我們仍然需要穩定分支，但是發行版真的會使用穩定分支么？讓我們一個一個看過去。

企業例子之一（紅帽）

紅帽有一個大型測試實驗室，有6000多臺各種各樣的機器分布在世界各地。實驗室使用Beaker并測試了大量不同的內核配置，目前內核測試主要集中在三個RHEL內核和兩個Fedora內核上，未來他們會計劃添加一些主線版本的內核。在紅帽內部，不同的團隊專注于他們感興趣的驅動，比如存儲團隊在測試各種存儲設備，而RDMA團隊在測試RDMA類型的硬件。所以，對于紅帽而言，他們只從穩定的樹上去挑選（cherry-pick）一些修復的補丁。 RHEL的每個小版本內核都有8-10萬個補丁，但是所有的這些補丁都來自上游而不是穩定分支。RHEL內核團隊會查看穩定的分支和最新的主線內核，然后尋找有必要使用的補丁。至于對應的測試則取決于這些補丁是應用于哪一個子系統; 一些子系統在補丁追溯方面做得很好，而其他子系統則較差。對于穩定內核的使用，一般Red Hat只是編譯了一下并用它來和RHEL內核做對比測試，以確定這些錯誤是來自上游還是在RHEL中引入的。

企業例子之二（SUSE和Ubuntu）

再看看SUSE，他們確實在構建穩定內核，但他們僅僅是為了挑選（cherry-pick）補丁。他們有考慮將穩定的內核測試添加到SUSE的測試網格（testing grid）中，但大家還不清楚它會對公司帶來什么樣的價值。Ubuntu面對的情況也是類似的：他們除了建立穩定的內核以外，并沒有對它們進行正式的測試。

企業例子之三（Linaro）

Linaro目前正在為谷歌開發一個使用內核自檢（kernel self-tests，縮寫kselftest）和Linux測試項目（Linux Test Project，縮寫LTP）來測試穩定的內核項目，這些測試會針對每個穩定的發布版本來進行。自檢測試的確能發現bug，但編寫這些自檢測試的人可能并不是引入大多數錯誤的人。所以自檢測試還只是一個開始，顯然Linaro還需要增加更多的測試。

所以綜合來看，版本發布者一般都只是關心，合并到穩定版本里的修復（fix）是否是正確的，但是他們只是從穩定版本中摘出修復（fix）然后放到自己的內核中做測試，對穩定內核本身的測試是非常有限的。于是有人建議可以由Linux基金會與Canonical，SUSE，Red Hat等公司一起組建一個合作項目，大家一起貢獻一部分機器同時形成一套測試套件來進行穩定內核的測試。

測試的不斷改善

例一：0天內核測試服務（0-Day kernel test service）。這個服務也不僅僅是構建和引導測試（build-and-boot tests），還包括一些性能測試。 kernelci.org項目也正在對許多不同的硬件進行構建和引導測試（build-and-boot tests），這些都是非常有價值的，但他們沒有做任何真正的功能性的測試。當然事情肯定會變得越來越好，大家不都是說“有比沒有好么”。

例二：LTP（Linux Test Project）。它可以測試很多東西，但也有很多地方它并不會去測試。它會被一些發行版使用，然后也肯定能在里面發現一些bug，但很明顯我們需要更多更好的測試套件。

例三：性能測試（benchmark）和模糊測試（fuzzing）。會上還討論了穩定內核的模糊測試。模糊測試上游內核是一種最好的選擇，因為所有問題的修補都在那里，但它仍然可以在發行版的內核中發現問題。目前syzkaller fuzzer已經可以針對它發現的問題自動生成小的測試用例，大家也覺得這些應該被加入自檢測試集。雖然有人提到一些BUG只在Kernel Address Sanitizer（縮寫KASAN）下才會出現，但這些測試在那些沒有被配置KASAN的內核上運行的時候是可以簡單地被跳過的。除了找BUG的測試之外，內核還需要更多的性能測試來發現性能退化（performance regressions），有人提到可以用Mel Gorman的MMTests作為“kbench”這一性能測試套件的基礎，只是這個套件對應的文檔很少了，所以我們需要在內核文檔目錄中建立一個測試套件目錄作為一個開始，但任何復雜的性能測試顯然需要更加深入的文檔。

例四：基準數字（single number）。有人提議說，如果我們有一個性能測試然后給出一個基準數字，而我們可以基于這個數字來判斷性能是否有退化就完美了（比如BogoMips背后的想法），當然有另外一些人會質疑是否真的存在這樣的測試系統。

例五：自我測試（self-tests）。越來越多的自我測試，正在被添加到內核主線中，但是穩定的內核卻不會從中受益。有些人正在使用較老的內核進行最新的自我檢測，于是有人提議也許自我測試本身應該被移植到穩定的內核樹中。

例六：神經網絡訓練。隨著BoF的結束，Levin要求發行版的維護者將他們正在使用的補丁推向穩定的分支中去。一般發行版中的問題在穩定內核中也一定存在。他最近一直在努力訓練一個神經網絡來識別適用于穩定內核的補丁，這引起了一些笑聲，但他說結果是“出人意料的好”。

內核測試的一些其他聲音

Greg Kroah-Hartman是穩定內核的維護者，他沒有參加BoF但是其實對BoF的討論內容也有興趣。于是第二天當Levin在一個小型會議中概括總結BoF的討論結果的時候，Greg給出了他的一些意見。

首先正如Levin所說，在BoF中大家提出了很多的觀點，但是并沒有什么相應的解決措施。有人建議應該向kernelci.org項目提供更多的硬件，Kroah-Hartman同時希望能看到更多的功能測試。另外還有一些人提議應該讓Linaro和kernelci.org一起努力合作這樣更好。

關于移植自我檢測（self-tests），Kroah-Hartman并不反對這個想法，只要它們能在出問題的內核上運行就可以。他也同意如果發行版能將它們的修補補丁打在穩定的分支（tree）上，那將是一件很好的事情，而且他提到Fedora和Debian已經在該領域做得很好。另一位與會者表示，發行版經常會盡快為用戶快速解決問題，然后才會做好上游內核的工作。 Kroah-Hartman表示，如果有BUG在上游內核中沒有被修復的話，他也不會在穩定內核中修復，這樣一方面上游內核和穩定內核做到了“bug兼容”，另一方面也給了那些廠商一些壓力來修復它。

結語

我們需要進行更多的內核測試，這是毋庸置疑的，但是它究竟應該采用什么樣的形式以及由誰來做仍然不清晰。如果幸運的話，在不久的將來這塊會有一些進展，同時也意味著我們有可能會更早地發現BUG。當然，完美是不可能的，但是我們大家都希望能夠減少內核里的錯誤，對么？另外一點，大家對于上游內核（upstream）的熱情是遠遠高于穩定內核（stable）的，所以對于穩定內核的測試肯定仍然會比較少，所以穩定內核的“穩定性”是大打折扣的。