linux內核的源代碼放在什么文件下

這篇文章主要介紹了linux內核的源代碼放在什么文件下的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇linux內核的源代碼放在什么文件下文章都會有所收獲，下面我們一起來看看吧。

linux內核的源代碼放在/usr/src/linux目錄下。內核源代碼的組成：1、arch目錄，包含了此核心源代碼所支持的硬件體系結構相關的核心代碼；2、include目錄，包括了核心的大多數include文件；3、init目錄，包含核心啟動代碼；4、mm目錄，包含所有的內存管理代碼；5、drivers目錄，包含系統中所有的設備驅動；6、Ipc目錄，包含核心的進程間通訊代碼。

linux內核的源代碼放在哪里

Linux的內核源代碼可以從很多途徑得到。一般來講，在安裝的linux系統下，/usr/src/linux目錄下的東西就是內核源代碼。

對于源代碼的閱讀，要想比較順利，事先最好對源代碼的知識背景有一定的了解。

Linux內核源代碼的組成如下(假設相對于linux目錄):

arch

這個子目錄包含了此核心源代碼所支持的硬件體系結構相關的核心代碼。如對于X86平臺就是i386。

include

這個目錄包括了核心的大多數include文件。另外對于每種支持的體系結構分別有一個子目錄。

init

此目錄包含核心啟動代碼。

mm

此目錄包含了所有的內存管理代碼。與具體硬件體系結構相關的內存管理代碼位于arch/*/mm目錄下，如對應于X86的就是arch/i386/mm/fault.c 。

drivers

系統中所有的設備驅動都位于此目錄中。它又進一步劃分成幾類設備驅動，每一種也有對應的子目錄，如聲卡的驅動對應于drivers/sound。

Ipc

此目錄包含了核心的進程間通訊代碼。

modules

此目錄包含已建好可動態加載的模塊。

fs Linux

支持的文件系統代碼。不同的文件系統有不同的子目錄對應，如ext2文件系統對應的就是ext2子目錄。

Kernel

主要核心代碼。同時與處理器結構相關代碼都放在arch/*/kernel目錄下。

Net

核心的網絡部分代碼。里面的每個子目錄對應于網絡的一個方面。

Lib

此目錄包含了核心的庫代碼。與處理器結構相關庫代碼被放在arch/*/lib/目錄下。

Scripts

此目錄包含用于配置核心的腳本文件。

Documentation

此目錄是一些文檔，起參考作用。

Linux 內核源碼分析方法

1 內核源碼之明晰

如果想透析Linux，深入操作系統的本質，閱讀內核源碼是最有效的途徑。我們都知道，想成為優秀的程序員，需要大量的實踐和代碼的編寫。編程固然重要，但是往往只編程的人很容易把自己局限在自己的知識領域內。如果要擴展自己知識的廣度，我們需要多接觸其他人編寫的代碼，尤其是水平比我們更高的人編寫的代碼。通過這種途徑，我們可以跳出自己知識圈的束縛，進入他人的知識圈，了解更多甚至我們一般短期內無法了解到的信息。Linux內核由無數開源社區的“大神們”精心維護，這些人都可以稱得上一頂一的代碼高手。透過閱讀Linux內核代碼的方式，我們學習到的不光是內核相關的知識，在我看來更具價值的是學習和體會它們的編程技巧以及對計算機的理解。

我也是通過一個項目接觸了Linux內核源碼的分析，從源碼的分析工作中，我受益頗多。除了獲取相關的內核知識外，也改變了我對內核代碼的過往認知：

1．內核源碼的分析并非“高不可攀”。內核源碼分析的難度不在于源碼本身，而在于如何使用更合適的分析代碼的方式和手段。內核的龐大致使我們不能按照分析一般的demo程序那樣從主函數開始按部就班的分析，我們需要一種從中間介入的手段對內核源碼“各個擊破”。這種“按需索取”的方式使得我們可以把握源碼的主線，而非過度糾結于具體的細節。

2．內核的設計是優美的。內核的地位的特殊性決定著內核的執行效率必須足夠高才可以響應目前計算機應用的實時性要求，為此Linux內核使用C語言和匯編的混合編程。但是我們都知道軟件執行效率和軟件的可維護性很多情況下是背道而馳的。如何在保證內核高效的前提下提高內核的可維護性，這需要依賴于內核中那些“優美”的設計。

3．神奇的編程技巧。在一般的應用軟件設計領域，編碼的地位可能不被過度的重視，因為開發者更注重軟件的良好設計，而編碼僅僅是實現手段問題——就像拿斧子劈柴一樣，不用太多的思考。但是這在內核中并不成立，好的編碼設計帶來的不光是可維護性的提高，甚至是代碼性能的提升。

每個人對內核的了理解都會有所不同，隨著我們對內核理解的不斷加深，對其設計和實現的思想會有更多的思考和體會。因此本文更期望于引導更多徘徊在Linux內核大門之外的人進入Linux的世界，去親自體會內核的神奇與偉大。而我也并非內核源碼方面的專家，這么做也只是希望分享我自己的分析源碼的經驗和心得，為那些需要的人提供參考和幫助，說的“冠冕堂皇”一點，也算是為計算機這個行業，尤其是在操作系統內核方面貢獻自己的一份綿薄之力。閑話少敘（已經羅嗦了很多了，囧~），下面我就來分享一下自己的Linix內核源碼分析方法。

2 內核源碼它到底難不難

從本質上講，分析Linux內核代碼和看別人的代碼沒有什么兩樣，因為擺在你面前的一般都不是你自己寫出來的代碼。我們先舉一個簡單的例子，一個陌生人隨便給你一個程序，并要你看完源碼后講解一下程序的功能的設計，我想很多自我感覺編程能力還可以的人肯定覺得這沒什么，只要我耐心的把他的代碼從頭到尾看完，肯定能找到答案，并且事實確實是如此。那么現在換一個假設，如果這個人是Linus，給你的就是Linux內核的一個模塊的代碼，你還會覺得依然那么輕松嗎？不少人可能會有所猶豫。同樣是陌生人（Linus要是認識你的話當然不算，呵呵~）給你的代碼，為什么給我們的感覺大相徑庭呢？我覺得有以下原因：

1．Linux內核代碼在“外界”看來多少有些神秘感，而且它很龐大，猛地擺在面前可能感覺無法下手。比如可能來源于一個很細小的原因——找不到main函數。對于簡單的demo程序，我們可以從頭至尾的分析代碼的含義，但是分析內核代碼這招就徹底失效了，因為沒有人能把Linux代碼從頭到尾看上一遍（因為確實沒有必要，用到時看就可以了）。

2．不少人也接觸過大型軟件的代碼，但多數屬于應用型項目，代碼的形式和含義都和自己常接觸的業務邏輯相關。而內核代碼不同，它處理的信息多數和計算機底層密切相關。比如操作系統、編譯器、匯編、體系結構等相關的知識的欠缺，也會讓閱讀內核代碼障礙重重。

3．分析內核代碼的方法不夠合理。面對大量的并且復雜的內核代碼，如果不從全局的角度入手，很容易陷入代碼細節的泥淖中。內核代碼雖然龐大，但是它也有它的設計原則和架構，否則維護它對任何人來說都是一個噩夢！如果我們理清代碼模塊的整體設計思路，再去分析代碼的實現，可能分析源碼就是一件輕松快樂的事情了。

針對這些問題，我個人是這樣理解的。如果沒有接觸過大型軟件項目，可能分析Linux內核代碼是一個很好的積累大型項目經驗的機會（確實，Linux代碼是我目前接觸到的最大的項目了！）。如果你對計算機底層了解的不夠透徹，那么我們可以選擇邊分析邊學習的方式去積累底層的知識。可能剛開始分析代碼的進度會稍顯遲緩，但是隨著知識的不斷積累，我們對Linux內核的“業務邏輯”會逐漸明朗起來。最后一點，如何從全局的角度把握分析的源碼，這也是我想與大家分享的經驗。

3 內核源碼分析方法

3.1 資料搜集

從人認識新事物的角度來講，在探索事物本質之前，必須有一個了解新鮮事物的過程，這個過程是的我們對新鮮事物產生一個初步的概念。比如我們想學習鋼琴，那么我們需要先了解彈奏鋼琴需要我們學習基本的樂理、簡譜、五線譜等基礎知識，然后學習鋼琴彈奏的技巧和指法，最后才能真正的開始練習鋼琴。

分析內核代碼也是如此，首先我們需要定位要分析的代碼涉及的內容。是進程同步和調度的代碼，是內存管理的代碼，還是設備管理的代碼，還是系統啟動的代碼等等。內核的龐大決定著我們不能一次性將內核代碼全部分析完成，因此我們需要給自己一個合理的分工。正如算法設計告訴我們的，要解決一個大問題，首先要解決它所涉及的子問題。

定位好要分析的代碼范圍，我們就可以動用手頭的一切資源，盡可能的全面了解該部分代碼的整體結構和大致功能。

這里所說的一切資源是指無論是Baidu、Google大型網絡搜索引擎，還是操作系統原理教材和專業書籍，亦或是他人提供的經驗和資料，甚至是Linux源碼提供的文檔、注釋和源碼標識符的名稱（不要小看代碼中的標識符的命名，有時它們能提供關鍵的信息）。總之這里的一切資源指的就是你能想到的一切可用資源。當然，我們不太可能通過這種形式的信息搜集獲得所有的我們想要的信息，我們只求盡可能全面即可。因為信息搜集的越全面，之后分析代碼的過程能使用的信息就更多，分析過程的困難就會越小。

這里舉一個簡單的例子，假定我們要分析Linux的變頻機制實現的代碼。目前為止我們僅僅是知道這個名詞而已，透過字面含義我們可以大致猜測它應該和CPU的頻率調節相關。通過信息搜集，我們應該能得到如下的相關的信息：

1．CPUFreq機制。

2．performance、powersave、userspace、ondemand、conservative調頻策略。

3．/driver/cpufreq/。

4．/documention/cpufreq。

5．P state和C state。

分析Linux內核代碼如果能搜集到這些信息，應該說是非常“幸運”了。畢竟有關Linux內核的資料確實不如.NET和JQuery那么豐富，不過這相比于十數年前，沒有強大的搜索引擎，沒有相關的研究資料的時期應該稱得上是“大豐收”時代了！我們通過簡單的“搜索”（可能會花費一到兩天的時間吧），甚至找到了這部分代碼所在的源碼文件目錄，不得不說這樣的信息簡直是“價值連城”！

3.2 源碼定位

從資料搜集中，我們“有幸”找到了源碼相關的源碼目錄。但是這并非意味著我們的確就是分析這個目錄下的源代碼。有時我們找到的目錄有可能是分散的，也有時我們找到的目錄下有很多和具體機器相關的代碼，而我們更關心的是待分析代碼的主要機制，而非與機器相關的特化代碼（這樣更有助于我們理解內核的本質）。因此，我們需要對資料中涉及代碼文件的資料進行仔細甄選。當然，這一步也不太可能一次性完成，誰也不能保證一次就能選擇出所有待分析的源碼文件而且一個不漏。但是我們也不必擔心，只要我們能抓住大多數模塊相關的核心源文件，通過后期對代碼的具體分析，就很自然的把它們全部找出來。

回到上述的例子中，我們認真的閱讀/documention/cpufreq下的文檔說明。目前的Linux源碼會把模塊相關的文檔說明保存在源碼目錄的documention的文件夾下，如果待分析的模塊沒有文檔說明，這多少會增加定位關鍵源碼文件的難度，但是不會導致我們找不到我們要分析的源碼。通過閱讀文檔說明，我們至少能關注到/driver/cpufreq/cpufreq.c這個源文件。通過這個對源文件的文檔說明，結合之前搜羅到的調頻策略，我們很容易關注到cpufreq_performance.c、cpufreq_powersave.c、cpufreq_userspace.c、cpufreq_ondemand、cpufreq_conservative.c這五個源文件。所有涉及的文件都找完了嗎？不用擔心，從它們開始分析，遲早能找到其他的源文件。如果在windows下使用sourceinsight閱讀內核源碼的話，我們通過函數的調用和查找符號引用等功能，結合代碼的分析可以很方便的找到另外的文件freq_table.c、cpufreq_stats.c和/include/linux/cpufreq.h。

按照搜索出的信息流動方向，我們完全可以定位到需要分析的源碼文件。源碼定位這一步并非十分關鍵，因為我們不需要找出所有源碼文件，我們可以把部分工作推遲到分析代碼的過程中。源碼定位也比較關鍵，找到一部分源碼文件是分析源碼的基礎。

3.3 簡單注釋

簡單注釋

在已定位好的源碼文件中，分析每個變量、宏、函數、結構體等代碼元素的大致含義和功能。之所以稱此為簡單注釋，并非指這部分的注釋工作很簡單，而是指這部分的注釋可以不必過分細化，只要大致描述出相關代碼元素的含義即可。相反，這里的工作其實是整個分析流程中最困難的一步。因為這是第一次深入到內核代碼的內部，尤其是對于首次分析內核源碼的人來說，大量的生疏GNU的C語法和鋪天蓋地的宏定義會令人很絕望。此時只要沉下心來，弄清每個關鍵的難點，才能保證以后碰到類似的難點不會再被困住。而且，我們對內核相關的其他知識會不斷的像樹一樣擴展開來。

比如在cpufreq.c文件開始就會出現“DEFINE_PER_CPU”宏的使用，我們通過查閱資料可以基本弄清這個宏的含義和功能。這里使用的手段和之前搜集資料使用的方法基本一致，另外我們也可以使用sourceinsight提供的轉到定義等功能查看它的定義，或者使用LKML（Linux Kernel Mail List）查閱。總之利用所有可能的手段，我們總能得到這個宏的含義——為每個CPU定義一個獨立使用的變量。

我們也不要強求一次就能把注釋描述的很準確（我們甚至都沒必要弄清每個函數的具體實現流程，只要弄清大致功能含義即可），我們結合搜集到的資料和后邊代碼的分析不斷的完善注釋的含義（源碼中原有的注釋和標識符命名在此很有利用價值）。通過不斷的注釋，不斷的查閱資料，不斷的修改注釋的含義。

當我們把所有涉及的源碼文件簡單注釋完畢后我們可以達到如下效果：

1．基本弄清了源碼中代碼元素存在的含義。

2．找出了該模塊所涉及的基本上全部的關鍵源碼文件。

結合之前搜集到的信息和資料對該待分析代碼的整體或者架構描述，我們可以將分析的結果和資料對比，以確定和修正我們對代碼的理解。這樣，通過一遍的簡單注釋，我們就可以從整體上把握了源碼模塊的主要結構。這也達到了我們簡單注釋的基本目的。

3.4 詳細注釋

完成代碼的簡單注釋后，可以認為對模塊的分析工作完成了一半了，剩下的內容就是對代碼的深入分析和徹底理解。簡單注釋總是不能將代碼元素的具體含義描述的十分精確，因此詳細注釋是十分有必要的。這一步中，我們需要弄清以下內容：

1．變量定義在何時被使用。

2．宏定義的代碼何時被使用。

3．函數的參數和返回值的含義。

4．函數的執行流程和調用關系。

5．結構體字段的具體含義和使用條件。

我們甚至可以把這一步稱為函數詳細注釋，因為函數之外的代碼元素的含義基本上在簡單注釋中已經比較明確了。而函數本身的執行流程、算法等是這部分注釋和分析的主要任務。

比如cpufreq_ondemand策略的實現算法（函數dbs_check_cpu中）是如何實現的。我們需要逐步分析該函數使用的變量和調用的函數等信息，弄清算法的來龍去脈。最好的結果，我們需要這些復雜函數的執行流程圖和函數調用關系圖，這是最直觀的表達方式。

通過這一步的注釋，我們基本上能完全把握待分析代碼整體的實現機制了。而所有的分析工作可以認為完成了80%。這一步工作尤其關鍵，我們必須盡量讓注釋的信息足夠的準確，才能更好的理解待分析代碼的內部模塊的劃分。雖然Linux內核中使用了宏語法“module_init”和“module_exit”聲明模塊文件，但是對模塊內部子功能的劃分是建立在充分了解模塊的功能基礎上的。只有正確劃分好模塊，我們才能弄清模塊提供了哪些外部函數和變量（使用EXPORT_SYMBOL_GPL或者EXPORT_SYMBOL導出的符號）。才能繼續下一步的模塊內標識符依賴關系分析。

3.5 模塊內部標識符依賴關系

通過第四步對代碼模塊的劃分，我們就可以很“輕松”地逐個對模塊進行分析。一般的，我們可以從文件底部的模塊出入口函數開始（“module_init”和“module_exit”聲明的函數，一般都在文件最后），根據它們調用的函數（自己定義的或者其他模塊的函數）和使用的關鍵變量（本文件內的全局變量或者其他模塊的外部變量）畫出“函數-變量-函數”依賴關系圖——我們稱為標識符依賴關系圖。

當然，模塊內標識符依賴關系并非是單純的樹形結構，很多情況是錯綜復雜的網絡關系。這時候，我們對代碼的詳細注釋的作用就體現出來了。我們根據函數本身的含義，將模塊進行子功能劃分，抽取出每個子功能的標識符依賴樹。

通過標識符依賴關系分析，可以很清晰的展示模塊定義的函數調用了那些函數，使用了哪些變量，以及模塊子功能之間的依賴關系——公用了哪些函數和變量等。

3.6 模塊間相互依賴關系

模塊間相互依賴關系

一旦將所有的模塊內部標識符依賴關系圖整理完畢，根據模塊使用的其他模塊的變量或函數，可以很容易得到模塊之間的依賴關系。

cpufreq代碼的模塊依賴關系可以表示為如下關系。

3.7 模塊架構圖

透過模塊間的依賴關系圖，可以很清楚的表達模塊在整個待分析代碼中的地位和功能。基于此，我們可以將模塊分類，整理出代碼的架構關系。

如cpufreq的模塊依賴關系圖所示，我們可以很清楚的看到所有的調頻策略模塊都是依賴于核心模塊cpufreq、cpufreq_stats和freq_table的。如果我們把被依賴的三個模塊抽象為代碼的核心框架的話，這些調頻策略模塊都是建立在這個框架之上的，它們負責和用戶層交互。而核心模塊cpufreq提供了驅動等相關的接口負責與系統底層交互。因此，我們可以得到如下的模塊架構圖。

當然，架構圖并非模塊的無機拼接，我們還需要結合查閱的資料去豐富架構圖的含義。因此，這里的架構圖的細節會隨著不同的人的理解有所偏差。但是架構圖主體的含義很基本一致的。至此，我們完成了待分析的內核代碼的所有分析工作。

關于“linux內核的源代碼放在什么文件下”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“linux內核的源代碼放在什么文件下”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。