Linux 內核概念和學習路線

作者：1w2b3l

http://blog.chinaunix.net/uid-24669930-id-4039377.html

1、前言

本文主要講解什麼是 Linux 內核，以及通過多張圖片展示 Linux 內核的作用與功能，以便於讀者能快速理解什麼是 Linux 內核，能看懂 Linux 內核。

擁有超過 1300 萬行的代碼，Linux 內核是世界上最大的開源項目之一，但是內核是什麼，它用於什麼?

2、什麼是內核

內核是與計算機硬件接口的易替換軟件的最低級別。它負責將所有以 “用戶模式” 運行的應用程序連接到物理硬件，並允許稱爲服務器的進程使用進程間通信 (IPC) 彼此獲取信息。

3、內核還要分種類？

是的，沒錯。

3.1 微內核

微內核只管理它必須管理的東西: CPU、內存和 IPC。計算機中幾乎所有的東西都可以被看作是一個附件，並且可以在用戶模式下處理。微內核具有可移植性的優勢，因爲只要操作系統仍然試圖以相同的方式訪問硬件，就不必擔心您是否更改了視頻卡，甚至是操作系統。

微內核對內存和安裝空間的佔用也非常小，而且它們往往更安全，因爲只有特定的進程在用戶模式下運行，而用戶模式不具有管理員模式的高權限。

3.1.1 Pros

3.1.2 Cons

3.2 單內核

單內核與微內核相反，因爲它們不僅包含 CPU、內存和 IPC，而且還包含設備驅動程序、文件系統管理和系統服務器調用等內容。單內核更擅長於訪問硬件和多任務處理，因爲如果一個程序需要從內存或運行中的其他進程中獲取信息，那麼它就有一條更直接的線路來訪問信息，而不需要在隊列中等待來完成任務。但是，這可能會導致問題，因爲在管理模式下運行的東西越多，如果行爲不正常，就會有越多的東西導致系統崩潰。

3.2.1 Pros

3.2.2 Cons

4、混合的內核

混合內核能夠選擇在用戶模式下運行什麼，以及在管理模式下運行什麼。通常情況下，設備驅動程序和文件系統 I/O 將在用戶模式下運行，而 IPC 和服務器調用將保持在管理器模式下。這是兩全其美，但通常需要硬件製造商做更多的工作，因爲所有驅動程序的責任都由他們來承擔。它還可能存在一些與微內核固有的延遲問題。

4.1 Pros

4.2 Cons

5、Linux 內核文件在哪裏

Ubuntu 中的內核文件存儲在 / boot 文件夾中，稱爲 vmlinux -version。vmlinuz 這個名字來自於 unix 世界，早在 60 年代，他們就把內核簡單地稱爲 “unix”，所以當內核在 90 年代首次開發時，Linux 就開始把內核稱爲 “Linux”。

當開發虛擬內存以便更容易地進行多任務處理時，將 “vm” 放在文件的前面，以顯示內核支持虛擬內存。有一段時間，Linux 內核被稱爲 vmlinux，但是內核變得太大，無法裝入可用的引導內存，因此壓縮了內核映像，並將末尾的 x 更改爲 z，以顯示它是用 zlib 壓縮的。並不總是使用相同的壓縮，通常用 LZMA 或 BZIP2 替換，一些內核簡單地稱爲 zImage。

在 / boot 文件夾中還有其他非常重要的文件，稱爲 initrd.img-version、system.map-version, config-version。initrd 文件用作一個小 RAM 磁盤，用於提取和執行實際的內核文件。這個系統。map 文件用於內核完全加載之前的內存管理，配置文件告訴內核在編譯內核映像時要加載哪些選項和模塊。

6、Linux 內核體系結構

因爲 Linux 內核是單片的，所以它比其他類型的內核佔用空間最大，複雜度也最高。這是一個設計特性，在 Linux 早期引起了相當多的爭論，並且仍然帶有一些與單內核固有的相同的設計缺陷。

爲了解決這些缺陷，Linux 內核開發人員所做的一件事就是使內核模塊可以在運行時加載和卸載，這意味着您可以動態地添加或刪除內核的特性。這不僅可以向內核添加硬件功能，還可以包括運行服務器進程的模塊，比如低級別虛擬化，但也可以替換整個內核，而不需要在某些情況下重啓計算機。

想象一下，如果您可以升級到 Windows 服務包，而不需要重新啓動……

7、內核模塊

如果 Windows 已經安裝了所有可用的驅動程序，而您只需要打開所需的驅動程序怎麼辦? 這本質上就是內核模塊爲 Linux 所做的。內核模塊，也稱爲可加載內核模塊 (LKM)，對於保持內核在不消耗所有可用內存的情況下與所有硬件一起工作是必不可少的。

模塊通常向基本內核添加設備、文件系統和系統調用等功能。lkm 的文件擴展名是. ko，通常存儲在 / lib/modules 目錄中。由於模塊的特性，您可以通過在啓動時使用 menuconfig 命令將模塊設置爲 load 或 not load，或者通過編輯 / boot/config 文件，或者使用 modprobe 命令動態地加載和卸載模塊，輕鬆定製內核。

第三方和封閉源碼模塊在一些發行版中是可用的，比如 Ubuntu，默認情況下可能無法安裝，因爲這些模塊的源代碼是不可用的。該軟件的開發人員 (即 nVidia、ATI 等) 不提供源代碼，而是構建自己的模塊並編譯所需的. ko 文件以便分發。雖然這些模塊像 beer 一樣是免費的，但它們不像 speech 那樣是免費的，因此不包括在一些發行版中，因爲維護人員認爲它通過提供非免費軟件 “污染” 了內核。

內核並不神奇，但對於任何正常運行的計算機來說，它都是必不可少的。Linux 內核不同於 OS X 和 Windows，因爲它包含內核級別的驅動程序，並使許多東西 “開箱即用”。希望您能對軟件和硬件如何協同工作以及啓動計算機所需的文件有更多的瞭解。

8、Linux 內核學習經驗總結

開篇

學習內核，每個人都有自己的學習方法，仁者見仁智者見智。以下是我在學習過程中總結出來的東西，對自身來說，我認爲比較有效率，拿出來跟大家交流一下。

內核學習，一偏之見；疏漏難免，懇請指正。

爲什麼寫這篇博客

剛開始學內核的時候，不要執着於一個方面，不要專注於一個子系統就一頭扎到實際的代碼行中去，因爲這樣的話，牽涉的面會很廣，會碰到很多困難，容易產生挫敗感，一個函數體中（假設剛開始的時候正在學習某個方面的某個具體的功能函數）很可能摻雜着其他各個子系統方面設計理念（多是大量相關的數據結構或者全局變量，用於支撐該子系統的管理工作）下相應的代碼實現，這個時候看到這些東西，紛繁蕪雜，是沒有頭緒而且很不理解的，會產生很多很多的疑問，

（這個時候如果對這些疑問糾纏不清，刨根問底，那麼事實上就是在學習當前子系統的過程中頻繁的去涉足其他子系統，這時候注意力就分散了），而事實上等了解了各個子系統後再回頭看這些東西的話，就簡單多了，而且思路也會比較清晰。所以，要避免 “只見樹木，不見森林”，不要急於深入到底層代碼中去，不要過早研究底層代碼。

我在大二的時候剛開始接觸內核，就犯了這個錯誤，一頭扎到內存管理裏頭，去看非常底層的實現代碼，雖然也是建立在內存管理的設計思想的基礎上，但是相對來說，比較孤立，因爲此時並沒有學習其它子系統，應該說無論是視野還是思想，都比較狹隘，所以代碼中牽涉到的其它子系統的實現我都直接跳過了，這一點還算聰明，當然也是迫不得已的。

我的學習方法

剛開始，我認爲主要的問題在於你知道不知道，而不是理解不理解，某個子系統的實現採用了某種策略、方法，而你在學習中需要做的就是知道有這麼一回事兒，然後纔是理解所描述的策略或者方法。

根據自己的學習經驗，剛開始學習內核的時候，我認爲要做的是在自己的腦海中建立起內核的大體框架，理解各個子系統的設計理念和構建思想，這些理念和思想會從宏觀上呈獻給你清晰的脈絡，就像一個去除了枝枝葉葉的大樹的主幹，一目瞭然；

當然，肯定還會涉及到具體的實現方法、函數，但是此時接觸到的函數或者方法位於內核實現的較高的層次，是主（要）函數，已經瞭解到這些函數，針對的是哪些設計思想，實現了什麼樣的功能，達成了什麼樣的目的，混個臉熟的說法在這兒也是成立的。

至於該主函數所調用的其它的輔助性函數就等同於枝枝葉葉了，不必太早就去深究。此時，也就初步建立起了內核子系統框架和代碼實現之間的關聯，關聯其實很簡單，比如一看到某個函數名字，就想起這個函數是針對哪個子系統的，實現了什麼功能。

我認爲此時要看的就是 LKD3，這本書算是泛泛而談，主要就是從概念，設計，大的實現方法上描述各個子系統，而對於具體的相關的函數實現的代碼講解很少涉及 (對比於 ULK3，此書主要就是關於具體函數代碼的具體實現的深入分析，當然，你也可以看，但是過早看這本書，會感覺很痛苦，很枯燥無味，基本上都是函數的實現)，很少，但不是沒有，這就很好，滿足我們當前的需求，還避免我們過早深入到實際的代碼中去。

而且本書在一些重要的點上還給出了寫程序時的注意事項，算是指導性建議。主要的子系統包括：內存管理，進程管理和調度，系統調用，中斷和異常，內核同步，時間和定時器管理，虛擬文件系統，塊 I/O 層，設備和模塊。（這裏的先後順序其實就是 LKD3 的目錄的順序）。

我學習的時候是三本書交叉着看的，先看 LKD3，專於一個子系統，主要就是了解設計的原理和思想，當然也會碰到對一些主要函數的介紹，但大多就是該函數基於前面介紹的思想和原理完成了什麼樣的功能，該書並沒有就函數本身的實現進行深入剖析。然後再看 ULK3 和 PLKA 上看同樣的子系統，但是並不仔細分析底層具體函數的代碼，只是粗略地、不求甚解地看，甚至不看。

因爲，有些時候，在其中一本書的某個點上，卡殼了，不是很理解了，在另外的書上你可能就碰到對同一個問題的不同角度的描述，說不準哪句話就能讓你豁然開朗，如醍醐灌頂。我經常碰到這種情況。

並不是說學習過程中對一些函數體的實現完全就忽略掉，只要自己想徹底瞭解其代碼實現，沒有誰會阻止你。我是在反覆閱讀過程中慢慢深入的。比如 VFS 中文件打開需要對路徑進行分析，需要考慮的細節不少 (.././ 之類的)，但是其代碼實現是很好理解的。

再比如，CFS 調度中根據 shedule latency、隊列中進程個數及其 nice 值 (使用的是動態優先級) 計算出分配給進程的時間片，沒理由不看的，這個太重要了，而且也很有意思。

ULK3 也會有設計原理與思想之類的概括性介紹，基本上都位於某個主題的開篇段落。但是更多的是對支持該原理和思想的主要函數實現的具體分析，同樣在首段，一句話綜述函數的功能，然後對函數的實現以 1、2、3，或者 a、b、c 步驟的形式進行講解。

我只是有選擇性的看，有時候對照着用 source insight 打開的源碼，確認一下代碼大體上確實是按書中所描述的步驟實現的，就當是增加感性認識。由於步驟中摻雜着各種針對不同實現目的安全性、有效性檢查，如果不理解就先跳過。這並不妨礙你對函數體功能實現的整體把握。

PLKA 介於 LKD3 和 ULK3 之間。我覺得 PLKA 的作者（看照片，真一德國帥小夥，技術如此了得）肯定看過 ULK，無論他的本意還是有意，總之 PLKA 還是跟 ULK 有所不同，對函數的仔細講解都做補充說明，去掉函數體中邊邊角角的情況，比如一些特殊情況的處理，有效性檢查等，而不妨礙對整個函數體功能的理解，這些他都有所交代，做了聲明；而且，就像 LKD3 一樣，在某些點上也給出了指導性編程建議。作者們甚至對同一個主要函數的講解的着重點都不一樣。

這樣的話，對我們學習的人而言，有助於加深理解。另外，我認爲很重要的一點就是 PLKA 針對的 2.6.24 的內核版本，而 ULK 是 2.6.11，LKD3 是 2.6.34。在某些方面 PLKA 比較接近現代的實現。其實作者們之所以分別選擇 11 或者 24，都是因爲在版本發行樹中，這兩個版本在某些方面都做了不小的變動，或者說是具有標誌性的轉折點（這些信息大多是在書中的引言部分介紹的，具體的細節我想不起來了）。

Intel V3，針對 X86 的 CPU，本書自然是系統編程的權威。內核部分實現都可以在本書找到其根源。所以，在讀以上三本書某個子系統的時候，不要忘記可以在 V3 中相應章節找到一些基礎性支撐信息。

在讀書過程中，會產生相當多的疑問，這一點是確信無疑的。大到搞不明白一個設計思想，小到不理解某行代碼的用途。各個方面，各種疑問，你完全可以把不理解的地方都記錄下來 (不過，我並沒有這麼做，沒有把疑問全部記下來，只標記了很少一部分我認爲很關鍵的幾個問題)，專門寫到一張紙上，不對，一個本上，我確信會產生這麼多的疑問，不然內核相關的論壇早就可以關閉了。

其實，大部分的問題（其中很多問題都是你知道不知道有這麼一回事的問題）都可以迎刃而解，只要你肯回頭再看，書讀百遍，其義自現。多看幾遍，前前後後的聯繫明白個七七八八是沒有問題的。我也這麼做了，針對某些子系統也看了好幾遍，切身體會。

當你按順序學習這些子系統的時候，前面的章節很可能會引用後面的章節，就像 PLKA 的作者說的那樣，完全沒有向後引用是不可能的，他能做的只是儘量減少這種引用而又不損害你對當前問題的理解。

不理解，沒關係，跳過就行了。後面的章節同樣會有向前章節的引用，不過這個問題就簡單一些了 ，你可以再回頭去看相應的介紹，當時你不太理解的東西，很可能這個時候就知道了它的設計的目的以及具體的應用。不求甚解只是暫時的。

比如說，內核各個子系統之間的交互和引用在代碼中的體現就是實現函數穿插調用，比如你在內存管理章節學習了的內存分配和釋放的函數，而你是瞭解內存在先的，在學習驅動或者模塊的時候就會碰到這些函數的調用，這樣也就比較容易接受，不至於太過茫然；再比如，你瞭解了系統時間和定時器的管理，再回頭看中斷和異常中 bottom half 的調度實現，你對它的理解就會加深一層。

子系統進行管理工作需要大量的數據結構。子系統之間交互的一種方式就是各個子系統各自的主要數據結構通過指針成員相互引用。學習過程中，參考書上在講解某個子系統的時候會對數據結構中主要成員的用途解釋一下，但肯定不會覆蓋全部（成員比較多的情況，例如 task_struct），對其它子系統基於某個功能實現的引用可能解釋了，也可能沒做解釋，還可能說這個變量在何處會做進一步說明。

所以，不要糾結於一個不理解的點上，暫且放過，回頭還可以看的。之間的聯繫可以在對各個子系統都有所瞭解之後再建立起來。其實，我仍然在強調先理解概念和框架的重要性。

等我們完成了建立框架這一步，就可以選擇一個比較感興趣的子系統，比如驅動、網絡，或者文件系統之類的。這個時候你再去深入瞭解底層代碼實現，相較於一開始就鑽研代碼，更容易一些，而且碰到了不解之處，或者忘記了某個方面的實現，此時你完全可以找到相應的子系統，因爲你知道在哪去找，查漏補缺，不僅完成了對當前函數的鑽研，而且可以回顧、溫習以前的內容，融會貫通的時機就在這裏了。

《深入理解 linux 虛擬內存》(2.4 內核版本)，LDD3，《深入理解 linux 網絡技術內幕》，幾乎每一個子系統都需要一本書的容量去講解，所以說，剛開始學習不宜對某個模塊太過深入，等對各個子系統都有所瞭解了，再有針對性的去學習一個特定的子系統。這時候對其它系統的援引都可以讓我們不再感到茫然、複雜，不知所云。

比如，LDD3 中的以下所列章節：構造和運行模塊，併發和競態，時間、延遲及延緩操作, 分配內存，中斷處理等，都屬於驅動開發的支撐性子系統，雖說本書對這些子系統都專門開闢一個章節進行講解，但是詳細程度怎麼能比得上 PLKA，ULK3，LKD3 這三本書，

看完這三本書，你會發現讀 LDD3 這些章節的時候簡直跟喝白開水一樣，太隨意了，因爲 LDD3 的講解比之 LKD3 更粗略。打好了基礎，PCI、USB、TTY 驅動，塊設備驅動，網卡驅動，需要了解和學習的東西就比較有針對性了。

這些子系統就屬於通用子系統，瞭解之後，基於這些子系統的子系統的開發—驅動 (需進一步針對硬件特性) 和網絡(需進一步理解各種協議)—相對而言，其學習難度大大降低，學習進度大大加快，學習效率大大提升。說着容易做來難。

達到這樣一種效果的前提就是：必須得靜下心來，認真讀書，要看得進去，PLKA，ULK3 厚得都跟磚頭塊兒一樣，令人望之生畏，如果沒有興趣，沒有熱情，沒有毅力，無論如何都是不行，因爲需要時間，需要很長時間。我並不是說必須打好了基礎纔可以進行驅動開發，只是說打好了基礎的情況下進行開發會更輕鬆，更有效率，而且自己對內核代碼的駕馭能力會更強大。這只是我個人見解，我自己的學習方式，僅供參考。

語言

PLKA 是個德國人用德語寫的，後來翻譯成英文，又從英文翻譯成中文，我在網上書店裏沒有找到它的紙質英文版，所以就買了中文版的。ULK3 和 LKD3 都是英文版的。大牛們寫的書，遣詞造句真的是簡潔，易懂，看原版對我們學習計算機編程的程序員來說完全不成問題，最好原汁原味。

如果一本書確實翻譯地很好，我們當然可以看中文版的，用母語進行學習，理解速度和學習進度當然是很快的，不作他想。看英文的時候不要腦子裏想着把他翻譯成中文，沒必要。

API 感想

“比起知道你所用技術的重要性，成爲某一個特別領域的專家是不重要的。知道某一個具體 API 調用一點好處都沒有，當你需要他的時候只要查詢下就好了。” 這句話源於我看到的一篇翻譯過來的博客。我想強調的就是，這句話針應用型編程再合適不過，但是內核 API 就不完全如此。

內核相當複雜，學習起來很不容易，但是當你學習到一定程度，你會發現，如果自己打算寫內核代碼，到最後要關注的仍然是 API 接口，只不過這些 API 絕大部分是跨平臺的，滿足可移植性。內核黑客基本上已經標準化、文檔化了這些接口，你所要做的只是調用而已。

當然，在使用的時候，最好對可移植性這一話題在內核中的編碼約定爛熟於心，這樣纔會寫出可移植性的代碼。就像應用程序一樣，可以使用開發商提供的動態庫 API，或者使用開源 API。同樣是調用 API，不同點在於使用內核 API 要比使用應用 API 瞭解的東西要多出許多。

當你瞭解了操作系統的實現—這些實現可都是對應用程序的基礎性支撐啊—你再去寫應用程序的時候，應用程序中用到的多線程，定時器，同步鎖機制等等等等，使用共享庫 API 的時候，聯繫到操作系統，從而把對該 API 的文檔描述同自己所瞭解到的這些方面在內核中的相應支撐性實現結合起來進行考慮，這會指導你選擇使用哪一個 API 接口，選出效率最高的實現方式。對系統編程頗有了解的話，對應用編程不無益處，甚至可以說是大有好處。

設計實現的本質，知道還是理解

操作系統是介於底層硬件和應用軟件之間的接口，其各個子系統的實現很大程度上依賴於硬件特性。書上介紹這些子系統的設計和實現的時候，我們讀過了，也就知道了，如果再深入考慮一下，爲什麼整體架構要按照這種方式組織，爲什麼局部函數要遵循這樣的步驟處理，知其然，知其所以然，如果你知道了某個功能的實現是因爲芯片就是這麼設計的，CPU 就是這麼做的，那麼你的疑問也就基本上到此爲止了。

再深究，就是芯片架構方面的設計與實現，對於程序員來講，無論是系統還是應用程序員，足跡探究到這裏，已經解決了很多疑問，因爲我們的工作性質偏軟，而這些東西實在是夠硬。

比如，ULK3 中講解的中斷和異常的實現，究其根源，那是因爲 Intel x86 系列就是這麼設計的，去看看 Intel V3 手冊中相應章節介紹，都可以爲 ULK3 中描述的代碼實現方式找到註解。還有時間和定時器管理，同樣可以在 Intel V3 對 APIC 的介紹中獲取足夠的信息，操作系統就是依據這些硬件特性來實現軟件方法定義的。

又是那句話，不是理解不理解的問題，而是知道不知道的問題。有時候，知道了，就理解了。在整個學習過程中，知道，理解，知道，理解，知道……，交叉反覆。

爲什麼開始和結尾都是知道，而理解只是中間步驟呢？世界上萬事萬物自有其規律，人類只是發現而已，實踐是第一位的，實踐就是知道的過程，實踐產生經驗，經驗的總結就是理論，理論源於實踐，理論才需要理解。我們學習內核，深入研究，搞來搞去，又回到了芯片上，芯片是物質的，芯片的功用基於自然界中物質本有的物理和電子特性。追本溯源，此之謂也。

動手寫代碼

紙上得來終覺淺，絕知此事要躬行。只看書是絕對不行的，一定要結合課本給出的編程建議自己敲代碼。剛開始就以模塊形式測試好了，或者自己編譯一個開發版本的內核。一臺機器的話，使用 UML 方式調試，內核控制路走到哪一步，單步調試看看程序執行過程，比書上的講解更直觀明瞭。一定要動手實際操作。

參考書

LDD3 Linux Device Driver 3rd LKD3 Linux Kernel Development 3rd ULK3 Understanding the Linux Kernel 3rd PLKA Professional Linux Kernel Architecture UML User Mode Linux Intel V3 Intel? 64 and IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B & 3C): System Programming Guide

作者在寫書的時候，都是以自己的理解組織內容，從自己的觀點看待一個主題，關注點跟作者自身有很大的關係。出書的時間有先後，後來人針對同一個主題想要出書而又不落入窠臼，最好有自己的切入方式，從自己的角度講解相關問題，這才值得出這本書，千篇一律是個掉價的行爲，書就不值錢了。

盡信書不如無書。

http://lwn.net/Articles/419855/ 此處是一篇關於 LKD3 的書評，指出了其中的錯誤，當你讀完的時候，不妨去找找，看一下自己在其中所描述的地方有什麼特別的印象。

http://lwn.net/Articles/161190 / 此處是一篇對 ULK3 的介紹，我認爲其中很關鍵的幾句話就可以給本書定位：

Many of the key control paths in the kernel are described, step by step;

一步一步地講述內核控制路徑的實現。

The level of detail sometimes makes it hard to get a sense for the > > > big picture, but it does help somebody trying to figure out how a particular function works.

對代碼講解的詳細程度有時候很難讓讀者把握住它的主旨大意，但是確實有助於讀者理解一 > 個特定的函數到底是如何工作的。

Indeed, that is perhaps the key feature which differentiates this book. It is very much a “how it works” book, designed to help people > understand the code.

事實上，這也正是本書與衆不同的地方。更像一個 “如何工作” 的書，幫助讀者理解代碼實現。

It presents kernel functions and data structures, steps the reader through them, but does not, for example, emphasize the rules for using them. UTLK is a study guide, not a programming manual.

本書描述了內核函數和數據結構，引導讀者穿行於其間，但是，並沒有着重強調使用它們的法則。UTLK 是一本學習指南，而不是編程手冊。

這幾句話對本書的描述非常到位。基於此，作爲指導性原則，我們就可以很有效率地使用它了。

這幾句話對本書的描述非常到位。基於此，作爲指導性原則，我們就可以很有效率地使用它了。

看一本技術書籍，書中的序言部分絕對是首先應該翻閱的，其次就是目錄。我發現在閱讀過程中我會頻繁的查看目錄，甚至是喜歡看目錄。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-SArNfssBBmVYVad91HgDg

猜你喜歡