Java開發者須要研究JDK，Linux開發者須要研究Kernel

本文轉載自：開源中國

2019 年是 Linux 內核誕生的第 28 年，1991 年 8 月 26 日，當年仍是大學生的 Linus Torvalds 向 comp.os.minix 新聞組的成員透露了出於「業餘愛好」而正在研究操做系統的消息。

Linux Kernel 是全球最大的開源項目，知名的科技公司幾乎都參與其中，包括微軟、谷歌、Red Hat、SUSE、Intel、Facebook、百度、阿里、華爲、Oracle 與騰訊等。同時，基於 Kernel 衍生出的發行版與各類周邊項目也讓其生態多姿多彩。

另外一方面，在當今雲原生高速發展的時代，其底層也大多基於 Linux Kernel，甚至連微軟也表示 Linux 運行了 Azure 工做負載的 50％ 以上。

Linux Kernel 短時間內不會過氣，而是會進一步影響到更多開發者，可是 Linux Kernel 的入門和實踐卻很困難，這讓許多初學者望而卻步，哪一個開發者說本身是 Linux Kernel 領域的，那其餘人一定會肅然起敬。

最近了解到有一本值得初學者學習的相關書籍《精通 Linux 內核——智能設備開發核心技術》，咱們就如何學習 Linux Kernel、Linux Kernel 2019 年的發展與相關應用領域等問題採訪了做者姜亞華，但願能給到想要了解、研究 Linux Kernel 的開發者一些啓發。如下是對話內容。

---

2019 年 Linux Kernel 進入了 5.x 時代，雖然 Linus 本身說從 4.20 到 5.x 只是由於本身手指不夠用，可是實際上以您的理解，這對於項目的生命週期管理、特性合併或者社區文檔建設等方面有沒有比較大的影響呢？

姜亞華：

5.x 其實更新蠻多的，patch 文件 40 多 M，涉及 10000 多個文件。

這是一個大版本更新，從用戶意識角度來說，4.x 已是舊的了，就好像 iPhone 更新，Apple 維持兩年一個大更新的節奏，買了一款 iPhone，下一年的小更新不會有啥感受，可是第二年大更新後，才以爲個人手機不是最流行的了。

新的項目，文檔等確定都須要向 5.x 看齊了。

從代碼角度來說，咱們能夠從內核更新的過程當中學習到不少優化的思路。我開始寫做《精通 Linux 內核——智能設備開發核心技術》的時候內核仍是 3.x，在書中也刻意保留了部分 3.x 的討論（sysfs、進場切換等），就是爲了經過對比總結這方面的經驗。

書中講到文件系統，可是沒有關於最近微軟件開放出來的 exFAT，猜測是由於您這書已經在此以前就寫了，那目前您有沒有繼續研究 exFAT 相關的內容呢？目前 exFAT 也已經在 5.4 中支持，它的能力上會帶來什麼影響呢？

姜亞華：

是的，我接下來打算再深刻一些模塊，exFAT 是其中之一。它的將來如何還很難說，Linux 已經有不少優秀的文件系統了，它們都通過了多年的驗證，bug 可能也相對少一些，exFAT 還須要在 Linux 上通過時間的考驗。

近期另外一個內核新特性也引發了普遍的討論，那就是內核鎖定，這個特性其實討論了多年，最後它的表現形式彷佛也挺讓人不解的。該特性限制了 root 角色的權限，可是 root 是系統的最高級權限都有不能訪問的地方，這對於 root 來講是挺奇怪的一件事情，在開發、運維或者平常使用上這會產生什麼比較大的影響嗎？

姜亞華：

內核鎖定主要是爲了防止 root 賬戶篡改內核代碼，從而在用戶態進程和代碼之間劃清界限。啓用鎖定模塊後，各類內核功能都會受到限制。其中包括對內核功能的訪問限制；對 /dev/mem 的讀寫操做的阻止；對 CPU MSR 訪問的限制；以及防止系統進入睡眠狀態等等。

這對 root 來講其實並不奇怪，它依然是超級用戶，能夠訪問全部正常的門。只不過內核鎖定把一些「後門」去掉了，這些門常閉或者不存在了。

引入內核鎖定（CONFIG_SECURITY）後，root 的訪問受到限制，開發、運維等過程當中使用的腳本或者 sequence 可能就不能工做了。好比 root 能夠經過 /dev/mem 文件訪問內存，引入內核鎖定後可能會受到限制。

說句題外話，root 是個挺危險的東西，慎用。記得我負責管理部門服務器的時候，有一次供應商幫我移植驅動的過程當中，安裝軟件的時候不當心刪除了一些文件，服務器斷電後就沒法啓動了。我帶着光盤，在無數服務器轟鳴的實驗室中，花了好幾天纔將它「搶救」回來。

相信不少開發者，或者剛在大學學計算機的人在瞭解了 Linux Kernel 以後都會想要去讀它的源碼，可是應該大部分都會不得其法，最終放棄。您是怎樣閱讀 Linux 內核源碼的呢？有什麼工具、方法與其它經驗能夠分享？

姜亞華：

我也是一行一行代碼看下來的，幾點建議供你們參考。

首先，先大概弄清原理，再仔細研究代碼，事半功倍。對於已經成熟的模塊，能夠先借助書籍和博客大體理解它的基本信息。

其次，邊讀代碼邊作筆記，防止看了後面忘記前面。作筆記的軟件蠻多的（好比微軟的 OneNote），選擇用的習慣的就好。

最後，自我激勵，堅持到底，最好是興趣使然。

好在你們不須要從頭開始了，我已經把本身看過的代碼的截圖放在隨書資料中了，算是一小段捷徑吧。這些截圖裏面，某函數、它調用的函數等函數調用關係使用紅線標示（以下圖），內容包括內存管理、文件系統和進程管理三大模塊。

你們遇到疑問也能夠聯繫我，共同探討，OSC 站內信（always_first_meet）或者郵件（linux_kernel_os@163.com）均可以。

Linux 內核十分龐大，閱讀源碼的時候哪些部分是最開始的時候必須的，而哪些部分能夠做爲後續針對性的補充？

姜亞華：

內核代碼量龐大，模塊間的關係也錯綜複雜，建議初學者能夠從相對簡單並且獨立的模塊入手，好比一個簡單設備的驅動。

先了解驅動自己的邏輯，以後是它的上下游，而後擴展到相關模塊，最後自由發揮。

舉個例子，在 drivers/input/keyboard 下面的文件是鍵盤驅動，咱們選擇一個文件。

第 1 階段，查看 xxx_probe 等函數，梳理控制和數據流程，理解驅動須要作什麼。

第 2 階段，適當拓展，代碼內調用的函數大概是如何實現的，驅動涉及的中斷、定時器、input 子系統等機制的原理，這些機制相對獨立，文檔也多，多花些時間便可。

第 3 階段，追根溯源，研究 xxx_probe 是如何被調用的，i2c 總線的驅動（假設鍵盤接 i2c 總線），device/device_driver/bus 的關係（驅動架構）。

階段 2 與 3 能夠同時進行。

第 4 階段，自由發揮，按照工做須要和興趣，進軍內存管理、文件系統和進程管理等模塊。

就算是可以閱讀源碼，另外一個問題也會出現，就是讀了源碼，理解了它的邏輯，可是有什麼用呢？最簡單的是增加了本身的見識，可是實際上這就像閱讀了一本書可是不輸出本身的理解與觀點，沒有太大的做用。您是怎麼看待而且怎麼解決這個問題的呢？

姜亞華：

研究內核有什麼用，這是一個值得深思的問題。

中國如今這個時候的確須要沉下心玩底層系統的人，中國渴望自主操做系統已經好久了，尤爲是如今這種多事之秋。可是若是沒有大批工程師在這個領域積澱的話，操做系統無疑是一種空談。

先不論將來的國產操做系統是否必定是 Linux 內核的，研究 Linux 內核自己也是很好的技術積累途徑。

僅僅從我的職業生涯角度出發，研究內核對我的技術的成長有極大幫助，能夠分多個層次看待。

第 1 層次，初識，對內核有大概的瞭解，須要花時間深刻工做相關的模塊。研究內核會佔用大量時間，產出並不明顯。

第 2 層次，入門，熟悉工做相關的模塊，理解內核模塊間的關係。研究內核會讓你豁然開朗，常常有「原來 xxx 是這麼實現的」之類的感嘆。

第 3 層次，熟悉或精通，對內核經常使用模塊有必定研究，熟悉代碼。即便是新模塊，也能夠快速釐清脈絡。

除了第 1 層次「浪費」時間外，花時間研究內核能夠反過來提升咱們的效率。研究到了必定程度後就能夠進入一個良性循環，研究得越多，效率越高，節省的時間越多，能夠研究的越多。

另外，看的代碼越多，越有能力解決錯綜複雜的問題，金老爺子也說「重劍無鋒，大巧不工」，絕對的實力纔是硬道理。

仍是 xxx_probe 的例子，若是咱們的 probe 沒有被調用，新手可能會檢查 device 和 device_driver 的名字是否匹配，研究過驅動架構的工程師可能分 device、device_driver 和 match 三部分檢查。

若是三部分看似都沒有問題，可是 probe 依然沒有調用呢？研究過代碼的工程師可能會想到 device 是否是已經和另外一個 device_driver 匹配了。

經驗能夠幫助咱們看到問題的關鍵部分，真正研究過代碼才能看到問題的本質。庖丁看到的不是牛，而是肌理結構，到了這種境界換成羊也是同樣的。

最近常常聽到一句話，「工做 xx 年，就是一年的工做經驗重複 xx 年」，若是隻是要求「會用」的層次，的確一年足夠，但工程師在這種狀況下遲早會失去核心競爭力。

有人傾向於使用結論，但要作的應該是總結和解釋結論。

如今學習 Linux Kernel，主要有哪些工做方向呢？又是哪些類型的公司、業務會主要須要這種能力？

姜亞華：

驅動工程師、嵌入式工程師、系統工程師、Linux 程序開發工程師，甚至運維工程師這些崗位都須要瞭解內核，就像從事 Java 開發的工程師須要研究 JDK 同樣，並非只有從事內核相關工做的工程師才須要研究內核，反過來懂內核的人向上發展也是很容易的。

有半導體相關業務的公司都須要這類人才，之前傳統的半導體公司需求大一些，但近幾年互聯網公司也紛紛涉足半導體領域，BAT 都包括在內。美國一系列動做以後，近期中國進入了芯片和操做系統研發熱潮，一大批芯片公司成立，燧原、平頭哥、寒武紀與商湯科技等等，它們也都須要內核相關的人才。

您這本書講到關於智能設備的開發，Linux Kernel 與 AI 有什麼特別大的關係呢？

姜亞華：

其實這個問題我在此次寫的書裏有解釋。

如上圖，「硬件廠商負責硬件，原語（primitives）庫通常也由他們維護，好比 AMD 的 MIOpen、Intel 的 MKL 和 Nvidia 的 cuDNN，多數程序員並不會接觸這部份內容，而是使用已有的 Framework。

Framework 的選擇也是多樣化的，Google 的 TensorFlow，Facebook 的 PyTorch，微軟的 CNDK，亞馬遜的 MXNet、Theano 和 Keras。很明顯，目前依然是百花齊放的局面，但技術的發展終歸只能是「三分天下」，甚至是「一統天下」。目前已經存在與這些 Framework 配套的工具，好比 Tensorboard，能夠用來查看 TensorFlow 的訓練狀態。

因爲深度學習計算量太大，並行計算技術也會有所涉及，好比 MPI（Message Passing Interface）通訊協議、英偉達的 NCCL（NVIDIA Collective Communications Library）。

數據對深度學習十分重要，大數據是必不可少的。數據做爲輸入，模型做爲輸出，應用於數據中心、我的計算機、機器人和無人駕駛汽車等設備中。

縱觀這整個過程，並無哪個環節提到了 Linux，但實際上多數環節都與 Linux 有關。雖然這些關係可能只有少數程序員關注，但隨着技術的成熟，新的智能設備，甚至新的操做系統，又會轉回到咱們熟悉的內核。

在您研究 Linux 內核的過程當中，有沒有以爲 Linux 內核其實還能夠用其它語言實現一次，這樣對於入門學習會好不少，好比用 Python 這種簡單理解的語言。這樣的想法可行嗎？會遇到什麼技術問題？

姜亞華：

內核裏面有不少代碼採用的都是面向對象的思想，好比 VFS 採用了較多面向對象程序的設計模式，像 command 與 template method 等，使用其它語言尤爲是面嚮對象語言來實現 Linux 內核是可行的，可是不得不說的是其它語言（好比 Python）很難有 C 語言的執行效率。

2019 年是 Linux Kernel 28 週年，分享一下您在這其中關於 Linux Kernel 印象最深的事情吧。

姜亞華：

Linux 內核是開源的，天生與微軟（更確切的說是 Windows）就是宿敵。微軟對 Linux 前期的敵對和近些年的轉變是件頗有趣的事情，敵對時期就很少說了，近幾年微軟宣佈「愛 Linux」，也作了不少實事，Azure、SQL Server 和 Visual Studio Code 等都有了 Linux 的身影。

這對 Linux 是好是壞先不說，這起碼說明了 Linux 的強大，有種「東方教主，千秋萬代，一統江湖」的感受哈哈。

這是一件關於 Linux Kernel 印象比較深的事情，還有另外一件也值得一提，那就是我今年寫了一本 Linux Kernel 相關的書籍《精通 Linux 內核——智能設備開發核心技術》，藉此也宣傳宣傳，同時但願可以經過這本書爲道友們提供些許幫助。

這本書基於 Linux 5.x，歷時五年，研究數百萬行代碼總結而成，共分爲五個部分，按照先易後難的順序剖析內核。首先介紹基礎知識，包括數據結構、中斷處理、內核同步和時間計算等，它們是理解後續章節的前提，在此基礎上詳細討論內存管理、文件管理和進程管理三個核心模塊，最後一部分昇華篇融合了前面多個模塊。重點和難點部分均配以圖表、代碼或實驗，力求深刻淺出。

除此以外，本書列舉了大量實例，分析了安卓操做系統的核心技術，使讀者可以深入的理解理論知識。本書的讀者須要熟悉 C 語言，可以對內核有必定了解更好。推薦初學者按照本書的既定順序閱讀，熟悉內核的讀者能夠直接閱讀三個核心模塊。

固然了，借這個平臺，也但願與道友們多多交流（包括但不限於本書的內容），歡迎你們跟我交流共同促進。另外本書是機械工業出版社《Linux 技術與應用叢書》的開篇之做，後續還會有一系列書籍出版，你們也能夠關注關注。 

---

採訪嘉賓介紹

姜亞華，一直從事與 Linux 內核和 Linux 編程相關的工做，研究內核代碼十多年，對多數模塊的細節如數家珍。曾負責華爲手機 Touch、Sensor 的驅動和軟件優化（包括 Mate、榮耀等系列），以及 Intel 安卓平臺 Camera 和 Sensor 的驅動開發（包括 Baytrail、Cherrytrail、Cherrytrail CR、Sofia 等）。現負責 DMA、Interrupt、Semaphore 等模塊的優化與驗證（包括 Vega、Navi 系列和多款 APU 產品）。