技術人攻略訪談二十九：平行世界守護者

文：Gracia (本文爲原創內容，部分或全文轉載均需通過做者受權，並保留完整的做者信息和技術人攻略介紹。Sai對本文亦有貢獻。)

導語：本期採訪對象吳峯光，任職於Intel開源技術中心。從第一次向內核社區提交patch，到成爲全職的開源貢獻者，峯光投身於開源領域已將近10年。做爲核心的內核代碼貢獻者，他有獨立維護的代碼tree，能夠直接向Linus Torvalds提交patch，並每一年受邀參加Kernel Summit峯會。在龐大的Linux開發者社區裏，能達到這幾點的，全球範圍內不過百人。

誕生於1991年的Linux，是整個開源世界的核心，以此爲基礎孕育出互聯網的繁榮。歷經二十幾年的發展，Linux的影響力早已超越操做系統核心自己，分散在全球各地的數千名開發者，經過網絡協做搭建心目中的理想國，竟能魔術般地創造出超越商業的力量。這不只是軟件工程的奇蹟，更是對傳統人類社會組織的重構。《大教堂與集市》這本書中，對Linux的這種顛覆性模式作了詳盡闡述：把單個黑客的自我實現緊密綁定在經過持續合做才能達成的目標上，造成開放和進化式的生態系統。在這個扁平的無政府主義世界中，代碼的完美程度是獲取聲望的惟一武器。純粹理想主義氣質的市集，最終造成了宏偉的大教堂，甚至影響了商業世界的走向，這其中究竟遵循什麼樣的法則？從峯光的分享中，咱們得以略窺一二。

或許是虛擬世界過於精彩，在現實中，峯光過得至爲簡樸。更爲可貴的是，他遇到了志趣相投的另外一半，一位名叫Sai的奇女子。婚後，他們在上海開始了「居無定所」的生活：兩人均可遠程辦公，省卻了上下班路上的通勤，跟據天天的活動範圍換不一樣賓館住，固然基本都遠離市區，開一輛外地牌照的車，僅一個後備箱就能夠容下所有行李。聽上去難以置信，他們卻樂在其中，像是生活在平行世界，精神上的富足遠比對物質的追逐來得重要。不知爲什麼，每當想起像峯光這樣的一羣人在守護着Linux，我對現實世界就多了一份信心。

技術人攻略：你從何時開始接觸內核開發？

我大學就讀於中科大自動化系，在那裏從本科一直唸到博士。大三開始接觸Linux，參加學校的Linux用戶協會。博士期間，實驗室幾個導師都是數學系出身，原本想跟隨導師作隨機過程方向的理論研究。但實驗室有項目須要用Linux，我在這方面比較熟，承擔起了開發和服務器維護的工做，天然而然轉向了應用領域。

博士期間接觸到一個863項目，須要搭建高性能的流媒體服務器，性能瓶頸卻卡在磁盤I/O上。優化過程當中，我花了一個多月時間，順藤摸瓜分析到系統底層，把內核I/O路徑整個看了一遍，開始對I/O預讀算法作改進。預讀是一種啓發式算法，經過預測應用程序的讀行爲提高性能。流媒體不一樣於通常的順序讀，更像同一個應用程序在作兩個區域的併發順序讀。完成預讀算法改進以後，我想讓你們都享受到這個好處，因而寫了組patch提交給社區。因爲是新手，徹底不知道內核代碼提交的流程和規範，花了一年多時間，一直更新到V12才被接收，由此走上了內核開發這條路。

技術人攻略：據說你畢業以後就進入Intel全職作開源，都作了哪些事情？

博士畢業進入Intel，在這裏待了5年多。Intel上海的開源團隊有兩、三百人，從最底層的內核，到Hadoop、瀏覽器、HTML五、Android等關鍵開源技術都有所覆蓋。

一開始，個人工做是博士期間項目的延續，繼續完善I/O預讀，後來開始作I/O回寫。從2012年到如今的主要工做是搭建了一套Linux內核測試服務。Linux應用場景普遍，從嵌入式設備到超級計算機都在用，測試的難度很高。I/O回寫的功能作了兩年，小部分時間花在作算法上，大部分時間都花在了各類場景的測試上，測試數據做圖形化分析，先後瀏覽了數萬張圖片，據此發現問題和改進算法最後提交的patch代碼只有1000餘行。

關於測試的複雜性能夠舉個例子，好比I/O預讀，不一樣應用程序有不一樣讀的大小、模式、併發度，還要考慮系統的內存壓力。I/O回寫更復雜，不只要測試不一樣應用程序，還要測每個文件系統。Linux的文件系統不少，包括ext四、XFS、Btrfs等。文件系統下面還有不一樣的存儲介質，磁盤、USB、SSD、NFS、iSCSI。從上到下，每一層都有一堆變數。甚至連內存大小都有關係，由於彈性緩存對內存敏感。

技術人攻略：這個測試服務能解決什麼問題？有哪些特色？

當時內核組想作些基本的內核測試，確保發出去的patch至少能夠被編譯和啓動。從追求效益最大化的角度出發，乾脆就把目標用戶鎖定爲整個社區，開發了一套測試雲服務。作測試不像開發新功能那樣酷，一開始很難找到志同道合者，整個測試系統從一我的、一臺機器開始。作的過程當中想盡辦法，在公司內部和社區去爭取資源，到如今已經有了幾十臺機器，團隊成員也有了好幾我的。

Linux的bug有兩種，一種是新bug，一種是Regression bug。新bug通常伴隨新功能產生，用戶願意承擔；Regression bug則要嚴重得多，本來正常的功能，在升級以後卻出現問題，這樣的狀況多了，用戶就不肯意升級了。開發者很難有能力作特別全面的測試，看代碼是否在其餘地方形成Regression bug。這正是咱們的測試服務能夠幫助到開發者的。Linux發展到這個地步，將測試歸入正軌很是重要。

咱們的測試覆蓋很是全，把能找到的內核tree都加進去了，有400多棵。剛推出的時候你們非常驚喜，由於速度很快，功能強大。最大的好處是開發者什麼都不用作，只管在本身的tree上開發，這邊的機器人自動就把tree上的新代碼拉下來，短則幾分鐘，長則一個小時，就能出Bug report。至關因而專業踩雷工具，踩得快，修復得快，其餘人就不會踩到了。這樣就把內核開發者互相之間的影響降到最低。

這套測試工具特別擅長抓Regression bug。基於Git裏面的bisect命令，測試系統經過二分法定位各類Regression bug。好比3.13內核沒問題，到3.14出問題了，這兩個版本之間有上萬個commit，若是不知道是哪一個commit形成這個問題，連該找誰修復都是問題。這種漫無目的的debug要求開發者很是專業，必須對內核各個方面都很是瞭解，才能感知和分析哪裏出了問題。但用bisect，至關於把計算機變成一個內核專家。bisect能夠迅速定位問題，找出有問題的commit，自動給做者和維護者發郵件。他們是該bug最相關的人，每每第一眼就看出問題出在哪裏，並瞭解如何修復最爲妥善。

大系統各方面出問題的機會多，依賴完善的測試工具，經過降維方式，用工程方法快速定位問題，Regression bug就能夠避免。這兩年一直在改進這套系統，測試是沒有止境的，能夠不斷增長覆蓋和測試種類。一開始作的是內核編譯，而後是內核啓動測試，再到功能測試、性能和功耗測試。

技術人攻略：如何給Linux內核社區提交代碼？整個社區的結構和決策過程是怎樣的？

Linux內核社區的規模很大，每個版本的代碼貢獻人數每每達到上千，支撐這個體系運轉的，是一套完善的開發流程。組織結構最頂層是Linus Torvalds，維護mainline tree，他只接受由maintainer提交的patch。maintainer下面是sub-maintainer，再下面是普通的developer。

核心maintainer是基於長期合做在社區創建起信任和威信的一羣人，大概有上百個，每人維護一棵或幾棵tree，按照子系統分紅CPU體系架構、網絡、文件系統、I/O、內存管理，及各種驅動等領域。新代碼就緒的時候，他們會給Linus Torvalds提請求，Linus認爲沒問題就merge。

任何人均可以提交patch，代碼被接受的關鍵有兩步，第一是有人review你的代碼，第二是maintainer接收代碼。提交patch以前，能夠經過查詢Git歷史，找到對代碼改動最多的人，給他發郵件，並cc給郵件列表。以確保代碼能被合適的人看到和review。

maintainer和活躍開發者均可以參與review，並給出意見。在review過程當中，一旦某人承認你的patch，會得到一個reviewed by的記錄，表示他們贊成你進Upstream。核心代碼通常須要得到兩個以上的reviewed by，若是你成功獲取了幾個reviewed by，這些參與review的人又是maintainer所信任的，那代碼被接收的問題就不大了。 若是出現意見分歧，Linus Torvalds擁有最終決定權。固然實際操做中，Linus不會常常出來PK，大多問題都由maintainer搞定。但Linus時不時也會在公開的郵件列表中發飆。

Linux社區有完善的運行機制，新人想融入社區，須要多花心思，不斷學習和適應。我花了一年多時間，才真正瞭解了社區運做的整個流程，該怎麼寫代碼，怎麼發代碼，怎麼跟人交互。這裏面的規則，不少文檔裏都有，只是看文檔是一回事，在實踐中落實是另外一回事。

內核社區的人來自全球各地，郵件是你們達成協做的主要交流方式，因此對寫郵件的格式有嚴格的要求。中間有不少細節，好比發郵件的程序要怎麼設置，要當心防止代碼被郵件客戶端自動換行，郵件該CC給誰，如何給別人回覆郵件，如何在回覆中保留相關的上下文。新人沒通過鍛鍊，就容易出錯。例如對於別人給出的review，不能採用top reply的方式回覆，而必需要到郵件的原文下方，一段一段地去回覆，逐條代表是否贊成，不一樣意的話，緣由是什麼。社區裏面review的資源十分珍貴，你們基本是在義務勞動，幫助改善你的patch。若是reviewer給出了意見，卻被忽略了，是不可接受的。

公司的代碼若是想進Upstream，也要遵循一套規範。建議一開始就在公開的郵件列表裏聲明，打算作什麼？怎麼作？在設計階段就把想法提出來，並蒐集你們的需求和反饋。從maintainer角度出發，他關心代碼是否解決通用性問題，不然系統會愈來愈複雜。並且代碼一旦push進Upstream，對maintainer和社區是長期維護的負擔，這也是爲何代碼的審覈會控制得如此嚴格。社區曾經有過一場很大的論戰，起源是Google對Android作了一些特殊擴展和優化，在市場上鋪開來以後想要把代碼push到內核。由於Google的作法違反了通用原則，沒有一早參與社區互動和徵詢意見，而是木已成舟了再提交，結果是社區不可避免的提出了許多尖銳的批評。這場論戰很是火爆，最後論戰各方共同對代碼作了一些重寫和改良，社區才最後接受。

技術人攻略：Linux如此成功，得益於其獨特的軟件開發組織形式，你認爲這種形式有哪些值得學習的地方？

從1991年到如今，Linux社區至關成功，Linus Torvalds一直在謀求更好的軟件開發組織形式。之前看過一本書，裏面有個話題頗有趣：若是把創造出Linux的這羣工程師，一開始就關到一個房間裏，還會誕生Linux這個系統嗎？結論是極可能不會，由於羣體性的誤差會致使項目走向另外的方向。

Linux社區花了很長的時間，才進化出現有這套開發流程和體系，每條規則都是慢慢造成的。這個系統全部的流程和方法論，都適應了互聯網環境下分佈式的協做方式，既可以讓你們各有貢獻，又不會形成太大損耗。雖然缺少面對面的交流，但對於深層、有挑戰性的問題，每一個人各自靜下心來思考出一套深入和周密的解決辦法，又比交流重要得多。網絡協做客觀上有利於保持你們獨立思考的空間。若是成爲一個羣體，就容易有羣體性的傾向。要麼被同化，要麼影響他人，要麼責任感退化，甚至產生辦公室政治。

社區的開發者來自不一樣地區、不一樣公司，多個公司的開發者相互協做，又彼此獨立，你們在博弈中決定系統的需求和走向。和公司項目的區別在於，同一個公司裏會有不少束縛，高層研發主管說句話，下面的人可能就聽從了。而互聯網上，你們是經過擺事實、講道理，而不是以身份、地位，或是服從個別公司的戰略或產品計劃來作決定。

Linux的發展和Windows不一樣，不會制定特別明確的目標。有人問Linus Torvalds，下個版本有什麼功能，Linus的回答是：不知道！這是一種順其天然的方式，新增功能徹底取決於開發者想要寫什麼，只要代碼通過了review、測試，達到了能夠merge的質量就能夠接收。Linux社區有不錯的自由競爭機制，你們以獨立貢獻者的身份提交代碼，淡化公司背景。重要的patch會被一輪又一輪的review，最後提交的版本每每跟初始版本大不同。固然更糟糕的狀況是直接被拒掉，或者有人提出別的競爭性方案。

這種模式也有不足之處，社區會常常性爆發Flame war口水戰，很耗時間。相比Firefox、Apache等社區，Linux社區的Flame war是比較尖銳的。這種尖銳也被不少人欣賞，雖然拒掉patch很讓人難堪，但的確對Linux長遠發展有好處。

技術人攻略：Linux系統的複雜度愈來愈高，穩定性會不會愈來愈難以控制？

Kernel Summit上每一年都會討論這個問題，歷史趨勢就是這樣的，任何系統都會愈來愈複雜。解決之道應該是更當心的開發和更強大的測試。

Linux發新版的速度很快，通常狀況下兩個月迭代一次，天天都有代碼提交，每週都有一個RC版本。在Linux2.二、2.4的時候，一兩年纔出一個版本，代碼之間互相影響的程度太大，系統搞得很是不穩定。因此如今提倡小步走，不要全部子系統都作大變更。Linux要發展，用戶想要新feature，系統確定會愈來愈大。能作到的就是對改代碼的要求愈來愈高，愈來愈當心。明確要求代碼要簡單、容易理解、尺寸不能太大。我在作內核開發的時候，任何一點代碼改動，都須要作各類場景的測試，這就致使寫內核代碼很是慢，天天能寫10行就很是好了，不斷錘鍊以後，真正能merge進去就沒多少了。

技術人攻略：你作Linux內核開發的成就感來自哪裏？

Linux的使用範圍很廣，作內核開發，我的的智慧能最大限度被人用到，因此收穫很大。固然也有代價，那就是進Upstream的難度很大，從能工做的代碼，到Upstream能接受的標準，這中間要完成的工做，遠比通常公司開發產品的標準要高。代碼一旦進入社區，就意味着要由maintainer維護，因此對代碼質量的要求不能放鬆，必須同時知足高效、通用、簡單的特色。

我在社區的位置介於maintainer和sub-maintainer之間，維護比較小的tree，但能夠直接給Linus Torvalds發請求。這兩年精力主要花在這個測試工具上，如今仍然在不斷完善它，好比加入了服務器的測試，未來會把手持設備系統加進來。Kernel Summit和Linus Torvalds都很重視測試，Linux內核要以質量、性能取勝，必定要有好的測試機制來保證。

對maintainer來講，越往裏作，經驗越豐富，作有趣的東西的機會就越少。review代碼的工做量很大，並且更可能是一種責任。由於他在這個領域最有經驗，對這塊的代碼最瞭解，雖然眼界愈來愈寬，但作的具體事情愈來愈無趣。review別人的代碼是個苦逼的事情，拒絕時不只要給出足夠理由，爲了培養潛在的貢獻者，還必須給他們引導，告訴他們怎麼作比較好。每一年Kernel Summit上，你們會針對這個問題吐槽，但暫時沒有很好的解決辦法。

技術人攻略：你第一次給社區提交patch的過程是怎樣的？對於有志於從事內核開發的人，你有什麼建議嗎？

從第一次提交I/O預讀patch，到接收爲止，花了一年多時間。期間我一共寫了十二個版本，從V1版本一直髮到V5，社區纔有人迴應，一直到V12才被接收。當時提交到Andrew Mortan維護的mm tree，在接受以後，他又感受個人算法太複雜，因而把我踢掉。Linux的核心原則是追求系統的簡單性，因此我把主要功能保留，把出現的機會少，影響面比較小的功能去掉，這樣才被最終接收。

這個過程當中有兩點很重要，第一是堅持，當別人不理你，或者是給你提不少意見的時候，你要頗有毅力地不斷知足他們，直到你們都承認。第二是提高本身，當個人patch沒人理的時候，我就繼續改進，包括看更多代碼，對代碼要吃得更透，作更多測試。還有就是在社區裏觀察和潛水，看郵件列表裏面別人是怎麼互動的。我當時重點看那些水平比較高的人，看他們怎麼給別人的patch作review，他們會提不少關於如何改進代碼的細緻意見，我從郵件中學習到不少東西，也就知道本身該怎麼作了。

想作內核開發，要動手，光讀代碼不可能深入理解。一旦你開始寫，會發現不少地方都理解錯了，原來意識不到的問題都會暴露。初次寫內核patch的人，行家一看就知道你是第一次寫，會有不少細節上的問題。入門的人想寫一個patch讓內核接收，最好從bug fix入手，bug會以很高的優先級被maintainer處理，幫着你完善patch。初學者能夠從這裏瞭解整個流程，而後再去作重要的東西。Linux社區是基於信任的，若是一開始就動一些關鍵問題，卻在格式上犯下低級錯誤，maintainer會不信任你。

作開源一個很大好處就是能快速提高能力，社區裏面有各類背景的高手，patch有任何問題都會被挑出來。有時候我寫patch，隱約感受某個地方還作得不夠好，但由於社區鼓勵快速給原型，因此就發出去了，結果確定有人指出其中的問題。社區會給你不少意想不到的東西，很快就能得到全方位的進步。

技術人攻略：Linux內核有哪些熱點和變化？

變化年年都有，對於操做系統來講，硬件是地基。新的硬件趨勢一出來，內核就要大改。上層應用有新的需求，內核也要適應。

多核給CPU帶來巨大挑戰，每一個CPU都有本身的內存，訪問不一樣內存的速度不一樣，這個過程要去優化。NUMA調度，非一致性內存架構，都是當前熱點。另外一大熱點是power-aware scheduling。若是系統只有一個進程在忙，其餘核是否是能關掉？若是有幾個進程在忙，能不能到一個核上去跑，讓它節能，或者讓它分散，得到更高的性能？CPU愈來愈複雜，操做系統須要有調頻策略，何時升頻，何時降頻，CPU某些部分的電源是否能夠關掉，這些都須要不斷改進。內核系統裏如今有愈來愈多難纏的問題，用戶究竟想要性能仍是節能，並無明確的結論，只能在權衡中前進。

存儲方面的變化，先看內存。內存特色是愈來愈大，原來系統內存是4G，以4k頁面的單位進行管理，至關於維護10的6次方個項目。但若是內存量級暴漲，4T變成常態，那就有必要增大內存管理的粒度。內存頁面是很是基本的數據結構，從4k變成64k，不是簡單的量級變化。CPU頁的單位就是4k，一旦硬件和內核的單位不是原子性對應，數據一致性問題就難以保證。

SSD也給存儲帶來了變化，內核假設磁盤是一個慢設備，如今快了好幾個量級，原來那些代碼開銷就大了。多隊列處理也是熱點，I/O量已經比一個CPU快，須要分到多個CPU。隨之而來的問題是，不一樣CPU處理這些中斷，對應的數據結構不能有耦合。多個CPU須要加鎖，而一旦加鎖，速度就慢下來了。

當前熱門的雲計算領域，也對內核提出了挑戰。KVM的I/O scalability還有待改進。目前CPU、內存、網絡、I/O等方面的cgroup隔離均可用了，只是I/O cgroup實如今塊設備層，對NFS等狀況不適用，此外由於I/O回寫要經過緩存，還實現不了真正的隔離。

技術人攻略：做爲一個內核高手，你的生活和社交圈子是怎樣的？

社交圈主要集中在網絡上這幫Linux社區的朋友。在生活中，我就算一我的關在屋裏也不會以爲悶，但若是讓我去跟其餘技術人社交，我也不排斥。通常這種聚會我不會主動去，但去了也會挺享受的。至於工做，我籤的合同是遠程辦公，公司容許這種比較自由的工做方式。我曾在廣西巴馬的長壽村住過一陣，緊張的工做以後，一出房間就能夠很放鬆，不像城市裏那種忙忙碌碌。那段時間天天登山，整我的都神清氣爽，工做效率也高。很喜歡這種生活，其實個人夢想就是住在山裏面，聽聽鳥叫，冥想，享受生活。

---

技術人攻略訪談是關於技術人生活和成長的系列訪問,由獨立媒體人Gracia創立和維護。報道內容以「人」爲核心，經過技術人的故事傳遞技術夢想；同時以小見大，見證技術的發展和行業的變遷。在這個史無前例的變革時代下，咱們的眼光將投向有關：創造力、好奇心、冒險精神，這樣一些長期被忽略的美好品質上。相信經過這樣一羣心懷夢想，而且正腳踏實地在改變世界的技術人，這些美好的東西將從新得到珍視。

聯繫方式 gracia@devlevelup.com
微博: @技術人攻略
訂閱：微信搜「技術人攻略」或「dev-levelup」

感謝SegmentFault提供博客專欄及推廣支持。
感謝迅達雲成提供雲主機及技術支持。