簡介
作用是將應用層序的請求傳遞給硬件，并充當底層驅動程序，對系統中的各種設備和組件進行尋址。目前支持模塊的動態裝卸(裁剪)。Linux內核就是基于這個策略實現的。Linux進程1.采用層次結構，每個進程都依賴于一個父進程。內核啟動init程序作為第一個進程。該進程負責進一步的系統初始化操作。init進程是進程樹的根，所有的進程都直接或者間接起源于該進程。virt/ ---- 提供虛擬機技術的支持。
linux內核深度解析 pdf，?
全文導讀
理解Linux內核最好預備的知識點：
非linux內核的系統？懂C語言
懂一點操作系統的知識
熟悉少量相關算法
懂計算機體系結構
Linux內核的特點：
結合了unix操作系統的一些基礎概念
?
kernel內核，
Linux內核的任務：
1.從技術層面講，內核是硬件與軟件之間的一個中間層。作用是將應用層序的請求傳遞給硬件，并充當底層驅動程序，對系統中的各種設備和組件進行尋址。
2.從應用程序的層面講，應用程序與硬件沒有聯系，只與內核有聯系，內核是應用程序知道的層次中的最底層。在實際工作中內核抽象了相關細節。
3.內核是一個資源管理程序。負責將可用的共享資源(CPU時間、磁盤空間、網絡連接等)分配得到各個系統進程。
4.內核就像一個庫，提供了一組面向系統的命令。系統調用對于應用程序來說，就像調用普通函數一樣。
內核實現策略：
1.微內核。最基本的功能由中央內核（微內核）實現。所有其他的功能都委托給一些獨立進程，這些進程通過明確定義的通信接口與中心內核通信。
2.宏內核。內核的所有代碼，包括子系統（如內存管理、文件管理、設備驅動程序）都打包到一個文件中。內核中的每一個函數都可以訪問到內核中所有其他部分。目前支持模塊的動態裝卸(裁剪)。Linux內核就是基于這個策略實現的。
哪些地方用到了內核機制？
1.進程（在cpu的虛擬內存中分配地址空間，各個進程的地址空間完全獨立;同時執行的進程數最多不超過cpu數目）之間進行通 ? 信，需要使用特定的內核機制。
2.進程間切換(同時執行的進程數最多不超過cpu數目)，也需要用到內核機制。
進程切換也需要像FreeRTOS任務切換一樣保存狀態，并將進程置于閑置狀態/恢復狀態。
3.進程的調度。確認哪個進程運行多長的時間。
Linux進程
1.采用層次結構，每個進程都依賴于一個父進程。內核啟動init程序作為第一個進程。該進程負責進一步的系統初始化操作。init進程是進程樹的根，所有的進程都直接或者間接起源于該進程。
2.通過pstree命令查詢。實際上得系統第一個進程是systemd，而不是init（這也是疑問點）
3.系統中每一個進程都有一個唯一標識符(ID),用戶（或其他進程）可以使用ID來訪問進程。
Linux內核源代碼的目錄結構
Linux內核源代碼包括三個主要部分：
1. 內核核心代碼，包括第3章所描述的各個子系統和子模塊，以及其它的支撐子系統，例如電源管理、Linux初始化等
2. 其它非核心代碼，例如庫文件（因為Linux內核是一個自包含的內核，即內核不依賴其它的任何軟件，自己就可以編譯通過）、固件集合、KVM（虛擬機技術）等
3. 編譯腳本、配置文件、幫助文檔、版權說明等輔助性文件
使用ls命令看到的內核源代碼的頂層目錄結構，具體描述如下。
include/ ---- 內核頭文件，需要提供給外部模塊（例如用戶空間代碼）使用。
kernel/ ---- Linux內核的核心代碼，包含了3.2小節所描述的進程調度子系統，以及和進程調度相關的模塊。
mm/ ---- 內存管理子系統（3.3小節）。
fs/ ---- VFS子系統（3.4小節）。
net/ ---- 不包括網絡設備驅動的網絡子系統（3.5小節）。
ipc/ ---- IPC（進程間通信）子系統。
arch// ---- 體系結構相關的代碼，例如arm, x86等等。
? ? arch//mach- ---- 具體的machine/board相關的代碼。
? ? arch//include/asm ---- 體系結構相關的頭文件。
? ? arch//boot/dts ---- 設備樹（Device Tree）文件。
init/ ---- Linux系統啟動初始化相關的代碼。
block/ ---- 提供塊設備的層次。
sound/ ---- 音頻相關的驅動及子系統，可以看作“音頻子系統”。
drivers/ ---- 設備驅動（在Linux kernel 3.10中，設備驅動占了49.4的代碼量）。
lib/ ---- 實現需要在內核中使用的庫函數，例如CRC、FIFO、list、MD5等。
crypto/ ----- 加密、解密相關的庫函數。
security/ ---- 提供安全特性（SELinux）。
virt/ ---- 提供虛擬機技術（KVM等）的支持。
usr/ ---- 用于生成initramfs的代碼。
firmware/ ---- 保存用于驅動第三方設備的固件。
samples/ ---- 一些示例代碼。
tools/ ---- 一些常用工具，如性能剖析、自測試等。
Kconfig, Kbuild, Makefile, scripts/ ---- 用于內核編譯的配置文件、腳本等。
COPYING ---- 版權聲明。
MAINTAINERS ----維護者名單。
CREDITS ---- Linux主要的貢獻者名單。
REPORTING-BUGS ---- Bug上報的指南。
Documentation, README ---- 幫助、說明文檔。
圖1 Linux系統層次結構
最上面是用戶（或應用程序）空間。這是用戶應用程序執行的地方。用戶空間之下是內核空間，Linux 內核正是位于這里。GNU C Library （glibc）也在這里。它提供了連接內核的系統調用接口，還提供了在用戶空間應用程序和內核之間進行轉換的機制。這點非常重要，因為內核和用戶空間的應用程序使用的是不同的保護地址空間。每個用戶空間的進程都使用自己的虛擬地址空間，而內核則占用單獨的地址空間。
Linux 內核可以進一步劃分成 3 層。最上面是系統調用接口，它實現了一些基本的功能，例如 read 和 write。系統調用接口之下是內核代碼，可以更精確地定義為獨立于體系結構的內核代碼。這些代碼是 Linux 所支持的所有處理器體系結構所通用的。在這些代碼之下是依賴于體系結構的代碼，構成了通常稱為 BSP（Board Support Package）的部分。這些代碼用作給定體系結構的處理器和特定于平臺的代碼。
Linux 內核實現了很多重要的體系結構屬性。在或高或低的層次上，內核被劃分為多個子系統。Linux 也可以看作是一個整體，因為它會將所有這些基本服務都集成到內核中。這與微內核的體系結構不同，后者會提供一些基本的服務，例如通信、I/O、內存和進程管理，更具體的服務都是插入到微內核層中的。每種內核都有自己的優點，不過這里并不對此進行討論。?
隨著時間的流逝，Linux 內核在內存和 CPU 使用方面具有較高的效率，并且非常穩定。但是對于 Linux 來說，最為有趣的是在這種大小和復雜性的前提下，依然具有良好的可移植性。Linux 編譯后可在大量處理器和具有不同體系結構約束和需求的平臺上運行。一個例子是 Linux 可以在一個具有內存管理單元（MMU）的處理器上運行，也可以在那些不提供 MMU 的處理器上運行。
Linux 內核的 uClinux 移植提供了對非 MMU 的支持。
?
圖2 Linux內核體系結構
Linux內核的主要組件有：系統調用接口、進程管理、內存管理、虛擬文件系統、網絡堆棧、設備驅動程序、硬件架構的相關代碼。
（1）系統調用接口
SCI 層提供了某些機制執行從用戶空間到內核的函數調用。正如前面討論的一樣，這個接口依賴于體系結構，甚至在相同的處理器家族內也是如此。SCI 實際上是一個非常有用的函數調用多路復用和多路分解服務。在 ./linux/kernel 中您可以找到 SCI 的實現，并在 ./linux/arch 中找到依賴于體系結構的部分。
（2）進程管理
進程管理的重點是進程的執行。在內核中，這些進程稱為線程，代表了單獨的處理器虛擬化（線程代碼、數據、堆棧和 CPU 寄存器）。在用戶空間，通常使用進程 這個術語，不過 Linux 實現并沒有區分這兩個概念（進程和線程）。內核通過 SCI 提供了一個應用程序編程接口（API）來創建一個新進程（fork、exec 或 Portable Operating System Interface [POSIX] 函數），停止進程（kill、exit），并在它們之間進行通信和同步（signal 或者 POSIX 機制）。
進程管理還包括處理活動進程之間共享 CPU 的需求。內核實現了一種新型的調度算法，不管有多少個線程在競爭 CPU，這種算法都可以在固定時間內進行操作。這種算法就稱為 O(1) 調度程序，這個名字就表示它調度多個線程所使用的時間和調度一個線程所使用的時間是相同的。O(1) 調度程序也可以支持多處理器（稱為對稱多處理器或 SMP）。您可以在 ./linux/kernel 中找到進程管理的源代碼，在 ./linux/arch 中可以找到依賴于體系結構的源代碼。
（3）內存管理
內核所管理的另外一個重要資源是內存。為了提高效率，如果由硬件管理虛擬內存，內存是按照所謂的內存頁 方式進行管理的（對于大部分體系結構來說都是 4KB）。Linux 包括了管理可用內存的方式，以及物理和虛擬映射所使用的硬件機制。不過內存管理要管理的可不止 4KB 緩沖區。Linux 提供了對 4KB 緩沖區的抽象，例如 slab 分配器。這種內存管理模式使用 4KB 緩沖區為基數，然后從中分配結構，并跟蹤內存頁使用情況，比如哪些內存頁是滿的，哪些頁面沒有完全使用，哪些頁面為空。這樣就允許該模式根據系統需要來動態調整內存使用。為了支持多個用戶使用內存，有時會出現可用內存被消耗光的情況。由于這個原因，頁面可以移出內存并放入磁盤中。這個過程稱為交換，因為頁面會被從內存交換到硬盤上。內存管理的源代碼可以在 ./linux/mm 中找到。
（4）虛擬文件系統
虛擬文件系統（VFS）是 Linux 內核中非常有用的一個方面，因為它為文件系統提供了一個通用的接口抽象。VFS 在 SCI 和內核所支持的文件系統之間提供了一個交換層（請參看圖4）。
圖3 Linux文件系統層次結構
在 VFS 上面，是對諸如 open、close、read 和 write 之類的函數的一個通用 API 抽象。在 VFS 下面是文件系統抽象，它定義了上層函數的實現方式。它們是給定文件系統（超過 50 個）的插件。文件系統的源代碼可以在 ./linux/fs 中找到。文件系統層之下是緩沖區緩存，它為文件系統層提供了一個通用函數集（與具體文件系統無關）。這個緩存層通過將數據保留一段時間（或者隨即預先讀取數據以便在需要是就可用）優化了對物理設備的訪問。緩沖區緩存之下是設備驅動程序，它實現了特定物理設備的接口。
（5）網絡堆棧
網絡堆棧在設計上遵循模擬協議本身的分層體系結構。回想一下，Internet Protocol (IP) 是傳輸協議（通常稱為傳輸控制協議或 TCP）下面的核心網絡層協議。TCP 上面是 socket 層，它是通過 SCI 進行調用的。socket 層是網絡子系統的標準 API，它為各種網絡協議提供了一個用戶接口。從原始幀訪問到 IP 協議數據單元（PDU），再到 TCP 和 User Datagram Protocol (UDP)，socket 層提供了一種標準化的方法來管理連接，并在各個終點之間移動數據。內核中網絡源代碼可以在 ./linux/net 中找到。
（6）設備驅動程序
Linux 內核中有大量代碼都在設備驅動程序中，它們能夠運轉特定的硬件設備。Linux 源碼樹提供了一個驅動程序子目錄，這個目錄又進一步劃分為各種支持設備，例如 Bluetooth、I2C、serial 等。設備驅動程序的代碼可以在 ./linux/drivers 中找到。
（7）依賴體系結構的代碼
盡管 Linux 很大程度上獨立于所運行的體系結構，但是有些元素則必須考慮體系結構才能正常操作并實現更高效率。./linux/arch 子目錄定義了內核源代碼中依賴于體系結構的部分，其中包含了各種特定于體系結構的子目錄（共同組成了 BSP）。對于一個典型的桌面系統來說，使用的是 x86 目錄。每個體系結構子目錄都包含了很多其他子目錄，每個子目錄都關注內核中的一個特定方面，例如引導、內核、內存管理等。這些依賴體系結構的代碼可以在 ./linux/arch 中找到。
如果 Linux 內核的可移植性和效率還不夠好，Linux 還提供了其他一些特性，它們無法劃分到上面的分類中。作為一個生產操作系統和開源軟件，Linux 是測試新協議及其增強的良好平臺。Linux 支持大量網絡協議，包括典型的 TCP/IP，以及高速網絡的擴展（大于 1 Gigabit Ethernet [GbE] 和 10 GbE）。Linux 也可以支持諸如流控制傳輸協議（SCTP）之類的協議，它提供了很多比 TCP 更高級的特性（是傳輸層協議的接替者）。
Linux 還是一個動態內核，支持動態添加或刪除軟件組件。被稱為動態可加載內核模塊，它們可以在引導時根據需要（當前特定設備需要這個模塊）或在任何時候由用戶插入。
Linux 最新的一個增強是可以用作其他操作系統的操作系統（稱為系統管理程序）。最近，對內核進行了修改，稱為基于內核的虛擬機（KVM）。這個修改為用戶空間啟用了一個新的接口，它可以允許其他操作系統在啟用了 KVM 的內核之上運行。除了運行 Linux 的其他實例之外， Microsoft Windows也可以進行虛擬化。惟一的限制是底層處理器必須支持新的虛擬化指令。
1．當被問到Linux體系結構（就是Linux系統是怎么構成的）時，我們可以參照下圖這么回答：從大的方面講，Linux體系結構可以分為兩塊：
（1）用戶空間：用戶空間中又包含了，用戶的應用程序，C庫
（2）內核空間：內核空間包括，系統調用，內核，以及與平臺架構相關的代碼
2．Linux體系結構要分成用戶空間和內核空間的原因：
1）現代CPU通常都實現了不同的工作模式，
以ARM為例：ARM實現了7種工作模式，不同模式下CPU可以執行的指令或者訪問的寄存器不同：
（1）用戶模式 usr?
（2）系統模式 ?sys
（3）管理模式?svc
（4）快速中斷 ?fiq
（5）外部中斷 ?irq
（6）數據訪問終止?abt
（7）未定義指令異常
以（2）X86為例：X86實現了4個不同級別的權限，Ring0—Ring3 ;Ring0下可以執行特權指令，可以訪問IO設備；Ring3則有很多的限制 ?
2）所以，Linux從CPU的角度出發，為了保護內核的安全，把系統分成了2部分；
3．用戶空間和內核空間是程序執行的兩種不同狀態，我們可以通過“系統調用”和“硬件中斷“來完成用戶空間到內核空間的轉移
4．Linux的內核結構（注意區分LInux體系結構和Linux內核結構）
Linux的這種platform driver機制和傳統的device_driver機制相比，一個十分明顯的優勢在于platform機制將本身的資源注冊進內核，由內核統一管理，在驅動程序中使用這些資源時通過platform_device提供的標準接口進行申請并使用。這樣提高了驅動和資源管理的獨立性，并且擁有較好的可移植性和安全性。下面是SPI驅動層次示意圖，Linux中的SPI總線可理解為SPI控制器引出的總線：
和傳統的驅動一樣，platform機制也分為三個步驟：
1、總線注冊階段：
內核啟動初始化時的main.c文件中的kernel_init()→do_basic_setup()→driver_init()→platform_bus_init()→bus_register(&platform_bus_type)，注冊了一條platform總線（虛擬總線，platform_bus）。
2、添加設備階段：
設備注冊的時候Platform_device_register()→platform_device_add()→(pdev→dev.bus = &platform_bus_type)→device_add()，就這樣把設備給掛到虛擬的總線上。
3、驅動注冊階段：
Platform_driver_register()→driver_register()→bus_add_driver()→driver_attach()→bus_for_each_dev(), 對在每個掛在虛擬的platform bus的設備作__driver_attach()→driver_probe_device(),判斷drv→bus→match()是否執行成功，此時通過指針執行platform_match→strncmp(pdev→name , drv→name , BUS_ID_SIZE),如果相符就調用really_probe(實際就是執行相應設備的platform_driver→probe(platform_device)。)開始真正的探測，如果probe成功，則綁定設備到該驅動。
從上面可以看出，platform機制最后還是調用了bus_register() , device_add() , driver_register()這三個關鍵的函數。
下面看幾個結構體：
struct platform_device
(/include/linux/Platform_device.h)
{
const char * name;
int id;
struct device dev;
u32 num_resources;
struct resource * resource;
};
Platform_device結構體描述了一個platform結構的設備，在其中包含了一般設備的結構體struct device ?dev;設備的資源結構體struct resource ? * resource;還有設備的名字const char * name。（注意，這個名字一定要和后面platform_driver.driver àname相同，原因會在后面說明。）
該結構體中最重要的就是resource結構，這也是之所以引入platform機制的原因。
struct resource
( /include/linux/ioport.h)
{
resource_size_t start;
resource_size_t end;
const char *name;
unsigned long flags;
struct resource *parent, *sibling, *child;
};
其中 flags位表示該資源的類型，start和end分別表示該資源的起始地址和結束地址(/include/linux/Platform_device.h)：
struct platform_driver
{
int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*suspend_late)(struct platform_device *, pm_message_t state);
int (*resume_early)(struct platform_device *);
int (*resume)(struct platform_device *);
struct device_driver driver;
};
Platform_driver結構體描述了一個platform結構的驅動。其中除了一些函數指針外，還有一個一般驅動的device_driver結構。
名字要一致的原因：
上面說的驅動在注冊的時候會調用函數bus_for_each_dev(), 對在每個掛在虛擬的platform bus的設備作__driver_attach()→driver_probe_device(),在此函數中會對dev和drv做初步的匹配，調用的是drv->bus->match所指向的函數。platform_driver_register函數中drv->driver.bus = &platform_bus_type，所以drv->bus->match就為platform_bus_type→match,為platform_match函數，該函數如下：
static int platform_match(struct device * dev, struct device_driver * drv)
{
struct platform_device *pdev = container_of(dev, struct platform_device, dev);
return (strncmp(pdev->name, drv->name, BUS_ID_SIZE) == 0);
}
是比較dev和drv的name，相同則會進入really_probe（）函數，從而進入自己寫的probe函數做進一步的匹配。所以dev→name和driver→drv→name在初始化時一定要填一樣的。
不同類型的驅動，其match函數是不一樣的，這個platform的驅動，比較的是dev和drv的名字，還記得usb類驅動里的match嗎？它比較的是Product ID和Vendor ID。
個人總結Platform機制的好處：
1、提供platform_bus_type類型的總線，把那些不是總線型的soc設備都添加到這條虛擬總線上。使得，總線——設備——驅動的模式可以得到普及。
2、提供platform_device和platform_driver類型的數據結構，將傳統的device和driver數據結構嵌入其中，并且加入resource成員，以便于和Open Firmware這種動態傳遞設備資源的新型bootloader和kernel 接軌。
?
因為Linux內核是單片的，所以它比其他類型的內核占用空間最大，復雜度也最高。這是一個設計特性，在Linux早期引起了相當多的爭論，并且仍然帶有一些與單內核固有的相同的設計缺陷。
為了解決這些缺陷，Linux內核開發人員所做的一件事就是使內核模塊可以在運行時加載和卸載，這意味著您可以動態地添加或刪除內核的特性。這不僅可以向內核添加硬件功能，還可以包括運行服務器進程的模塊，比如低級別虛擬化，但也可以替換整個內核，而不需要在某些情況下重啟計算機。
想象一下，如果您可以升級到Windows服務包，而不需要重新啟動……
如果Windows已經安裝了所有可用的驅動程序，而您只需要打開所需的驅動程序怎么辦?這本質上就是內核模塊為Linux所做的。內核模塊，也稱為可加載內核模塊(LKM)，對于保持內核在不消耗所有可用內存的情況下與所有硬件一起工作是必不可少的。
模塊通常向基本內核添加設備、文件系統和系統調用等功能。lkm的文件擴展名是.ko，通常存儲在/lib/modules目錄中。由于模塊的特性，您可以通過在啟動時使用menuconfig命令將模塊設置為load或not load，或者通過編輯/boot/config文件，或者使用modprobe命令動態地加載和卸載模塊，輕松定制內核。
第三方和封閉源碼模塊在一些發行版中是可用的，比如Ubuntu，默認情況下可能無法安裝，因為這些模塊的源代碼是不可用的。該軟件的開發人員(即nVidia、ATI等)不提供源代碼，而是構建自己的模塊并編譯所需的.ko文件以便分發。雖然這些模塊像beer一樣是免費的，但它們不像speech那樣是免費的，因此不包括在一些發行版中，因為維護人員認為它通過提供非免費軟件“污染”了內核。
內核并不神奇，但對于任何正常運行的計算機來說，它都是必不可少的。Linux內核不同于OS X和Windows，因為它包含內核級別的驅動程序，并使許多東西“開箱即用”。希望您能對軟件和硬件如何協同工作以及啟動計算機所需的文件有更多的了解。
開篇
學習內核，每個人都有自己的學習方法，仁者見仁智者見智。以下是我在學習過程中總結出來的東西，對自身來說，我認為比較有效率，拿出來跟大家交流一下。
內核學習，一偏之見；疏漏難免，懇請指正。
為什么寫這篇博客
剛開始學內核的時候，不要執著于一個方面，不要專注于一個子系統就一頭扎到實際的代碼行中去，因為這樣的話，牽涉的面會很廣，會碰到很多困難，容易產生挫敗感，一個函數體中（假設剛開始的時候正在學習某個方面的某個具體的功能函數）很可能摻雜著其他各個子系統方面設計理念（多是大量相關的數據結構或者全局變量，用于支撐該子系統的管理工作）下相應的代碼實現，這個時候看到這些東西，紛繁蕪雜，是沒有頭緒而且很不理解的，會產生很多很多的疑問，（這個時候如果對這些疑問糾纏不清，刨根問底，那么事實上就是在學習當前子系統的過程中頻繁的去涉足其他子系統，這時候注意力就分散了），而事實上等了解了各個子系統后再回頭看這些東西的話，就簡單多了，而且思路也會比較清晰。所以，要避免 “只見樹木，不見森林”，不要急于深入到底層代碼中去，不要過早研究底層代碼。
我在大二的時候剛開始接觸內核，就犯了這個錯誤，一頭扎到內存管理里頭，去看非常底層的實現代碼，雖然也是建立在內存管理的設計思想的基礎上，但是相對來說，比較孤立，因為此時并沒有學習其它子系統，應該說無論是視野還是思想，都比較狹隘，所以代碼中牽涉到的其它子系統的實現我都直接跳過了，這一點還算聰明，當然也是迫不得已的。
我的學習方法
剛開始，我認為主要的問題在于你知道不知道，而不是理解不理解，某個子系統的實現采用了某種策略、方法，而你在學習中需要做的就是知道有這么一回事兒，然后才是理解所描述的策略或者方法。
根據自己的學習經驗，剛開始學習內核的時候，我認為要做的是在自己的腦海中建立起內核的大體框架，理解各個子系統的設計理念和構建思想，這些理念和思想會從宏觀上呈獻給你清晰的脈絡，就像一個去除了枝枝葉葉的大樹的主干，一目了然；當然，肯定還會涉及到具體的實現方法、函數，但是此時接觸到的函數或者方法位于內核實現的較高的層次，是主（要）函數，已經了解到這些函數，針對的是哪些設計思想，實現了什么樣的功能，達成了什么樣的目的，混個臉熟的說法在這兒也是成立的。至于該主函數所調用的其它的輔助性函數就等同于枝枝葉葉了，不必太早就去深究。此時，也就初步建立起了內核子系統框架和代碼實現之間的關聯，關聯其實很簡單，比如一看到某個函數名字，就想起這個函數是針對哪個子系統的，實現了什么功能。
我認為此時要看的就是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是一本學習指南，而不是編程手冊。
這幾句話對本書的描述非常到位。基于此，作為指導性原則，我們就可以很有效率地使用它了。
看一本技術書籍，書中的序言部分絕對是首先應該翻閱的，其次就是目錄。我發現在閱讀過程中我會頻繁的查看目錄，甚至是喜歡看目錄。
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
