㈠ linux /sbin/init程序的代碼在busybox的什麼地方
BusyBox 命令中支持的選項 BusyBox 中的命令並不支持所有可用選項，不過這些命令都包含了常用的選項。如果我們需要知道一個命令可以支持哪些選項，可以使用 --help 選項來調用這個命令，如清單 12 所示。
清單 12. 使用 --help 選項調用命令
$ ./busybox wc --help
BusyBox v1.1.1 (2006.04.09-15:27+0000) multi-call binary
Usage: wc [OPTION]... [FILE]...
Print line, word, and byte counts for each FILE, and a total line if
more than one FILE is specified. With no FILE, read standard input.
Options:
-c print the byte counts
-l print the newline counts
-L print the length of the longest line
-w print the word counts
$
這些特定的數據只有在啟用了 CONFIG_FEATURE_VERBOSE_USAGE 選項時才可以使用。如果沒有這個選項，我們就無法獲得這些詳細數據，但是這樣可以節省大約 13 KB 的空間。
向 BusyBox 中添加新命令
向 BusyBox 添加一個新命令非常簡單，這是因為它具有良好定義的體系結構。第一個步驟是為新命令的源代碼選擇一個位置。我們要根據命令的類型（網路，shell 等）來選擇位置，並與其他命令保持一致。這一點非常重要，因為這個新命令最終會在 menuconfig 的配置菜單中出現（在下面的例子中，是 Miscellaneous Utilities 菜單）。
對於這個例子來說，我將這個新命令稱為 newcmd，並將它放到了 ./miscutils 目錄中。這個新命令的源代碼如清單 13 所示。
清單 13. 集成到 BusyBox 中的新命令的源代碼
#include "busybox.h"
int newcmd_main( int argc, char *argv[] )
{
㈡ 在源碼中init函數最後的運行/sbin/init從哪裡來的
呵呵，到你看的這里的時候，
kernel 已經啟動完成了，
/sbin/init 是應用層的程序，
和 kernel 不是一起的。
kernel 啟動完成後，會主動將控制權移交給 /sbin/init，繼續完成應用層的初始化，這也就是你看到的這幾行代碼。
這個程序不是 kernel 的一部分，任何人用任何語言都可以編寫這個 /sbin/init 程序，你自己也可以編～
不過雖說是如此，System V 對於 init 程序還是有個規范的，man init 就可以看到關於它所應該實現的功能的描述。
在我的 Linux(FC3) 上，/sbin/init 程序是 rpm 包 SysVinit-2.85-34 提供的。
事實上，根據我的觀察，各個發行版自己都改過 init，這一點可以從啟動時屏幕上列印出的信息中看到。
[ 關閉窗口 ]
㈢ linux 內核啟動完如何到init
Linux內核為不同驅動的載入順序對應不同的優先順序，定義了一些宏：
include\linux\init.h
#define pure_initcall(fn) __define_initcall("0",fn,1)
#define core_initcall(fn) __define_initcall("1",fn,1)
#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
#define postcore_initcall(fn) __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
#define arch_initcall(fn) __define_initcall("3",fn,3)
#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
#define subsys_initcall(fn) __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn) __define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn) __define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
#define __initcall(fn) device_initcall(fn)
把自己的驅動的函數名用這些宏去定義之後，
就會對應不同的載入時候的優先順序。
其中，我們寫驅動中所用到的mole_init對應的是
#define mole_init(x) __initcall(x);
而
#define __initcall(fn) device_initcall(fn)
所以，驅動對應的載入的優先順序為6
在上面的不同的優先順序中，
數字越小，優先順序越高。
同一等級的優先順序的驅動，載入順序是鏈接過程決定的，結果是不確定的，我們無法去手動設置誰先誰後。
不同等級的驅動載入的順序是先優先順序高，後優先順序低，這是可以確定的。
所以，像我們之前在驅動中用：
mole_init(i2c_dev_init);
mole_init(as352x_afe_init);
mole_init(as352x_afe_i2c_init);
mole_init(enc28j60_init);
所以，大家都是同一個優先順序去初始化，
最後這些驅動載入的順序，可以查看在根目錄下，
生成的system.map：
。。。
c00197d8 t __initcall_alignment_init5
。。。。。
c00197f4 t __initcall_default_rootfsrootfs
c00197f8 t __initcall_timer_init_sysfs6
c00197fc t __initcall_clock_dev_init6
。。。
c00198d8 t __initcall_loop_init6
c00198dc t __initcall_net_olddevs_init6
c00198e0 t __initcall_loopback_init6
c00198e4 t __initcall_enc28j60_init6
。。。
c0019900 t __initcall_as352x_spi_init6
c0019904 t __initcall_spidev_init6
。。。
c0019920 t __initcall_i2c_dev_init6
c0019924 t __initcall_as352x_afe_i2c_init6
c0019928 t __initcall_as352x_afe_init6
。。。
c0019970 t __initcall_random32_reseed7
c0019974 t __initcall_seqgen_init7
c0019978 t __initcall_rtc_hctosys7
c001997c T __con_initcall_start
c001997c t __initcall_con_init
c001997c T __initcall_end
。。。
此處就是由於
c0019920 t __initcall_i2c_dev_init6
c0019924 t __initcall_as352x_afe_i2c_init6
c0019928 t __initcall_as352x_afe_init6
在
c00198e4 t __initcall_enc28j60_init6
之前，所以我這里才要去改。。。
知道原理，能想到的，就是
要麼把
as352x_afe_init
改到
enc28j60_init
之前一級，即優先順序為5。
即在驅動中，調用：
fs_initcall(as352x_afe_init)；
要麼把
enc28j60_init
改到
as352x_afe_init
之後，即優先順序為7
即在驅動中，調用：
late_initcall(enc28j60_init)；
但是，此處麻煩就麻煩在，
如果把
as352x_afe_init
改到
enc28j60_init
之前一級，
發現後面網卡初始化enc28j60_init中，雖然讀取晶元ID對了，
但是後面的IP-auto configure 有問題。
所以放棄。
如果把
enc28j60_init
改到
as352x_afe_init
之後，
但是，從system.map中看到的是，優先順序為7的驅動中，明顯有幾個驅動，
也是和網卡初始化相關的，所以，這樣改，嘗試後，還是失敗了。
所以，沒法簡單的通過調整現有的驅動的順序，去實現順序的調整。
最後，被逼無奈，想到了一個可以實現我們需求的辦法，
那就是，單獨定義一個優先順序，把afe相關的初始化都放到那裡面去，
這樣，就可以保證，其他沒什麼相關的沖突了。
最後證實，這樣是可以實現目的的。
具體添加一個新的優先順序的步驟如下：
1.定義新的優先順序
include\linux\init.h中：
#define pure_initcall(fn) __define_initcall("0",fn,1)
#define core_initcall(fn) __define_initcall("1",fn,1)
#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
#define postcore_initcall(fn) __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
#define arch_initcall(fn) __define_initcall("3",fn,3)
#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
#define subsys_initcall(fn) __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn) __define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#if 1
#define prev_device_initcall(fn) __define_initcall("6",fn,6)
#define prev_device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define device_initcall(fn) __define_initcall("7",fn,7)
#define device_initcall_sync(fn) __define_initcall("7s",fn,7s)
#define late_initcall(fn) __define_initcall("8",fn,8)
#define late_initcall_sync(fn) __define_initcall("8s",fn,8s)
#else
#define device_initcall(fn) __define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
#endif
2.用對應新的宏，定義我們的驅動：
prev_device_initcall(i2c_dev_init);
prev_device_initcall(as352x_afe_i2c_init);
prev_device_initcall(as352x_afe_init);
做到這里，本以為可以了，但是編譯後，在system.map中，發現之前優先順序為7的那幾個函數，
被放到system.map最後了，而不是預想的，
在優先順序7之後，在
c001997c T __con_initcall_start
c001997c t __initcall_con_init
c001997c T __initcall_end
之前。
最後，發現時沒有把對應的鏈接文件中的宏加進去：
3.
include\asm-generic\vmlinux.lds.h
#if 1
#define INITCALLS \
*(.initcall0.init) \
*(.initcall0s.init) \
*(.initcall1.init) \
*(.initcall1s.init) \
*(.initcall2.init) \
*(.initcall2s.init) \
*(.initcall3.init) \
*(.initcall3s.init) \
*(.initcall4.init) \
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
*(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
*(.initcall7s.init) \
*(.initcall8.init) \
*(.initcall8s.init)
#else
#define INITCALLS \
*(.initcall0.init) \
*(.initcall0s.init) \
*(.initcall1.init) \
*(.initcall1s.init) \
*(.initcall2.init) \
*(.initcall2s.init) \
*(.initcall3.init) \
*(.initcall3s.init) \
*(.initcall4.init) \
*(.initcall4s.init) \
*(.initcall5.init) \
*(.initcall5s.init) \
*(.initcallrootfs.init) \
*(.initcall6.init) \
*(.initcall6s.init) \
*(.initcall7.init) \
*(.initcall7s.init)
#endif
最後，再重新編譯，就可以實現我們要的，
和afe相關的驅動初始化，都在網卡enc28j60_init之前了。
也就可以在網卡裡面讀晶元ID了。
當然，對應編譯生成的system.map文件中，
對應的通過mole_init定義的驅動，優先順序也都變成7了。
而late_initcall對應優先順序8了。
註：當前開發板arm的板子，所以，對應的load 腳本在：
linux-2.6.28.4\arch\arm\kernel\vmlinux.lds
看起來，應該是這個文件：
linux-2.6.28.4\arch\arm\kernel\vmlinux.lds.S
生成上面那個腳本的。
vmlinux.lds中的這一行：
__initcall_start = .;
*(.initcallearly.init) __early_initcall_end = .; *(.initcall0.init) *(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init) *(.initcall2.init) *(.initcall2s.init) *(.initcall3.init) *(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init) *(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init) *(.initcall6.init) *(.initcall6s.init) *(.initcall7.init) *(.initcall7s.init)
就是將之前那些對應的init類型的函數，展開，放到這對應的位置。
㈣ linux中init的詳細用法是什麼呀
init模塊
一般來說，Linux程序只能用另一個Linux程序啟動。例如，登錄Linux終端程序Mingetty。
但終端程序又由誰啟動呢？在計算機上啟動Linux時，內核裝入並啟動init程序。然後init程序
裝載硬碟和啟動終端程序。登錄終端程序時，它啟動命令行界面Shell。
在計算機上啟動Linux之後，init程序監視任何關閉計算機的信號，如不間斷電源（UPS）發
生的電源故障信號和重新啟動命令。
init是Linux系統操作中不可缺少的程序之一。
所謂的init進程，它是一個由內核啟動的用戶級進程。
內核自行啟動（已經被載入內存，開始運行，並已初始化所有的設備驅動程序和數據結構等
）之後，就通過啟動一個用戶級程序init的方式，完成引導進程。所以,init始終是第一個進程
（其進程編號始終為1）。
內核會在過去曾使用過init的幾個地方查找它，它的正確位置（對Linux系統來說）
是/sbin/init。如果內核找不到init，它就會試著運行/bin/sh，如果運行失敗，系統的啟動也
會失敗。
一、什麼是INIT:
init是Linux系統操作中不可缺少的程序之一。
所謂的init進程，它是一個由內核啟動的用戶級進程。
內核自行啟動（已經被載入內存，開始運行，並已初始化所有的設備驅動程序和數據結構等
）之後，就通過啟動一個用戶級程序init的方式，完成引導進程。所以,init始終是第一個進程
（其進程編號始終為1）。
內核會在過去曾使用過init的幾個地方查找它，它的正確位置（對Linux系統來說）
是/sbin/init。如果內核找不到init，它就會試著運行/bin/sh，如果運行失敗，系統的啟動也
會失敗。
二、運行級別
那麼，到底什麼是運行級呢？
簡單的說，運行級就是操作系統當前正在運行的功能級別。這個級別從1到6 ，具有不同的
功能。
不同的運行級定義如下：(可以參考Red Hat Linux 裡面的/etc/inittab）
# 0 - 停機（千萬不能把initdefault 設置為0 ）
# 1 - 單用戶模式
# 2 - 多用戶，沒有 NFS
# 3 - 完全多用戶模式(標準的運行級)
# 4 - 沒有用到
# 5 - X11 （xwindow)
# 6 - 重新啟動 （千萬不要把initdefault 設置為6 ）
這些級別在/etc/inittab 文件里指定。這個文件是init 程序尋找的主要文件，最先運行的
服務是放在/etc/rc.d 目錄下的文件。在大多數的Linux 發行版本中，啟動腳本都是位於
/etc/rc.d/init.d中的。這些腳本被用ln 命令連接到 /etc/rc.d/rcn.d 目錄。(這里的n 就是
運行級0-6)
三、運行級別的配置
運行級別的配置是在/etc/inittab行內進行的，如下所示：
12 : 2 : wait : / etc / init.d / rc 2
第一個欄位是一個任意指定的標簽；
第二個欄位表示這一行適用於運行那個級別（這里是2）；
第三個字 段表示進入運行級別時，init應該運行第四個欄位內的命令一次，而且init應該
等待該命令結束。/etc/init.d/rc命令運行啟動和終止輸入以便進入運行級別2時所需的任何命
令。
第四個欄位中的命令執行設置運行級別時的一切「雜活」。它啟動已經沒有運行的服務，終
止不應該再在新運行級別內運行的服務。根據Linux版本的不同，採用的具體命令也不同，而且
運行級別的配置也是有差別的。
init啟動時，它會在/etc/inittab內查找一個代碼行，這一行指定了默認的運行級別：
id : 2 : initdefault :
你可以要求init在啟動時，進入非默認運行級別，這是通過為內核指定一個「single」或「
emergency」 命令行參數來實現的。比如說，內核命令行參數的指定可通過LILO來執行。這樣一
來，你就可以選擇單用戶模式了（即運行級別1）。
系統正在運行時，telinit命令可更改運行級別。運行級別發生變化時， init 就會
從/etc/inittab運行相應的命令。
四、/etc/inittab中的特殊配置
/etc/inittab中，有幾個特殊的特性，允許init重新激活特殊事件。這些特殊特性都是用第
三個欄位中的特殊關鍵字標記出來的。比如：
1. powerwait
允許init在電源被切斷時，關閉系統。其前提是具有U P S和監視U P S並通知init電源已被
切斷的軟體。
2. ctrlaltdel
允許init在用戶於控制台鍵盤上按下C t r l + A l t + D e l組合鍵時，重新啟動系統。
注意，如果該系統放在一個公共場所，系統管理員可將C t r l + A l t + D e l組合鍵配置為
別的行為，比如忽略等。
3. sysinit
系統啟動時准備運行的命令。比如說，這個命令將清除/tmp。
上面列出的特殊關鍵字尚不完整。其他的關鍵字及其使用詳情，可參考你的inittab手冊頁
。
五、在單用戶模式下引導
一個重要的運行級別就是單用戶模式（運行級別1），該模式中，只有一個系統管理員使用
特定的機器，而且盡可能少地運行系統服務，其中包含登錄。單用戶模式對少數管理任務（比如
在/usr分區上運行fsck）而言，是很有必要的，因為這需要卸載分區，但這是不可能的，除非所
有的服務系統已被殺死。
一個正在運行的系統可以進入單用戶模式，具體做法是利用init，請求運行級別1。內核啟
動時，在內核命令行指定single或emergency關鍵字，就可進入運行級別1了。內核同時也為init
指定命令行， init從關鍵字得知自己不應該採用默認的運行級別（內核命令行的輸入方式和你
啟動系統的方式有關）。
有時，以單用戶模式進行啟動是必要的，這樣一來，用戶在裝入分區之前，或至少在裝入分
散的/usr分區之前，能手工運行fsck（在分散的文件系統上，任何活動都可能使其更為分散，所
以應該盡可能地運行fsck）。
如果自動化的fsck在啟動時失敗了，啟動腳本init的運行將自動進入單用戶模式。這樣做是
為了防止系統使用不連貫的文件系統，這個文件系統是f s c k不能自動修復的。文件系統不連
貫的現象極為少見，而且通常會導致硬碟的不連貫或實驗性的內核釋放，但最好能做到防患於未
然。
由於安全上的考慮，在單用戶模式下，啟動外殼腳本之前，配置得當的系統會要求用戶提供
root密碼。否則，它會簡單地為L I L O輸入合適的一行代碼，以r o o t的身份登錄（當然，如
果/etc/passwd已經由於文件系統的問題而不連貫了，就不適合這里的原則了，為對付這種情況
，你最好隨時准備一張啟動盤）。
不同的運行級有不同的用處，也應該根據自己的不同情形來設置。
例如，如果丟失了root口令，那麼可以讓機器啟動進入單用戶狀態。在啟動後的 lilo 提示
符下輸入：
init=/bin/sh rw 使機器進入運行級1 ，並把 root 文件系統掛為讀寫。他會跳過所有系統
認證，讓你可以使用passwd 程序來改變root口令，然後啟動到一個新的運行級。
㈤ 怎麼開始讀Linux內核源碼
本人是一名 android display方面的工程師，結合實際工作經驗聊聊(觀點未必正確)
1. 准備工作：選擇什麼樣的版本，使用什麼樣的工具，這個需要考慮好。
如果是要參考書的話，kernel版本一般都應該選擇和書裡面同步的版本，不要去選擇最新的版本。因為最新的版本，各種改動比較多，反而對不上書了。
工具問題，你可以選擇windows下的source insight，也可以選擇linux下vim+ctags；
2. 第一遍瀏覽，我建議是先把kernel裡面的 start_kernel() 函數裡面的東西看清楚（不一定看明白），看看這個過程中，出現了什麼玩意，有哪些分支，並將分支初略的畫出一張圖來（當然，我自己並沒做到這一點，有點諷刺了）。
這裡面最重要的幾個地方，我個人認為，應該搞明白mole機制，它是怎麼通過編譯鏈接腳本放在特定的區域，然後系統起來後，又是如何去(按照什麼規則)去載入這些模塊；
應該搞明白sysfs系統，這個對於驅動和用戶空間的連接，有非常大的作用；
系統調用的open()應該走一遭，看看用戶空間到kernel之間參數是如何傳遞，又是怎麼通過vfs系統，把open的動作最終落實到某一個驅動的open()上去的；
對kernel啟動過程中，內存的分配演算法，是怎麼從夥伴演算法切換到最終的演算法上，也應該略有耳聞；對fork()函數的過程有所明白。
對kernel中基本的數據結構實現過程、鎖機制實現過程要有概念：
這一部分，總結起來，應該看的路線是：
start_kernel()
mole_init() 宏實現 // 看這個的時候，強烈建議，把makefile真正的意圖弄明白
open() 系統調用
fork() 系統調用
sysfs 框架實現
雙鏈表是如何實現的;
鎖最終是依靠什麼來保證的?（其實還是硬體來保證的）
對於數據結構和鎖這部分，就按照《Linux內核設計與實現》裡面的東西挨個挨個看。有興趣，自己也可以實現一個雙鏈表公共API，隨便哪個項目，一旦用上，直接拋進去，也未嘗不可。
第一遍瀏覽，竊以為，上面這幾部分看明白後，kernel的代碼對你依然很難，但已經不再有神秘的面紗。
後續，你想研究某個模塊，直接快速定位到那邊去就行。
3. 在完全用眼睛看完上面這部分內容後，kernel的路或許找到了，但是，萬里長征的第一步，並沒有邁出。這個時候，動手是很重要的了。
網上有各種方法，比如說，去kernel maillist裡面訂閱bug，然後自己試著解bug，此方法可取，而且是非常好。這里會遇到一個問題是，我們該怎麼調試？
有人是架各種虛擬機或者多台物理機一起開干，這個可以有。(但是本人動手能力確實有限，這個沒干成，本人是後面藉助了公司的開發板)
如果你也像我一樣，動手能力不足，如果你恰巧是手機或者類似手機開發公司的，你可以直接使用公司的開發機，通過串口log，將printk()的級別設置為3，把你需要的信息列印出來；
如果你是學生或者愛好者，可以花500左右人民幣，去淘寶上買一個開發板，也是帶串口的，所有的debug信息都是通過串口列印出來，保存到一個Log文件中，然後分析；
至於買什麼樣的板子，你可以隨便選擇，經典的s3c2440也行，高端點的樹莓派，或者全志什麼的，都可以。(不推薦全志，他們添加和修改硬體比較多，驅動也許不好搞)
4. 選擇你喜歡的模塊，進行深入研究，通過log列印，反復推敲，這個時候，bug是最好的導師。多關注kernel/Documents/ 目錄下的文檔。
你需要注意的是，一定要把該模塊無關的東西砍掉，否則，生命是有限的，而代碼是無限的。
最後一句話是，在用眼睛看完後，思考過後，還得動手，然後再思考。否則，只讀的話，僅能掃盲。
㈥ 如何查看linux系統源碼
一般在Linux系統中的/usr/src/linux*.*.*（*.*.*代表的是內核版本，如2.4.23）目錄下就是內核源代碼（如果沒有類似目錄，是因為還沒安裝內核代碼）。另外還可從互連網上免費下載。注意，不要總到http://www.kernel.org/去下載，最好使用它的鏡像站點下載。請在http://www.kernel.org/mirrors/里找一個合適的下載點，再到pub/linux/kernel/v2.6/目錄下去下載2.4.23內核。
代碼目錄結構
在閱讀源碼之前，還應知道Linux內核源碼的整體分布情況。現代的操作系統一般由進程管理、內存管理、文件系統、驅動程序和網路等組成。Linux內核源碼的各個目錄大致與此相對應，其組成如下（假設相對於Linux-2.4.23目錄）：
1.arch目錄包括了所有和體系結構相關的核心代碼。它下面的每一個子目錄都代表一種Linux支持的體系結構，例如i386就是Intel CPU及與之相兼容體系結構的子目錄。PC機一般都基於此目錄。
2.include目錄包括編譯核心所需要的大部分頭文件，例如與平台無關的頭文件在include/linux子目錄下。
3.init目錄包含核心的初始化代碼（不是系統的引導代碼），有main.c和Version.c兩個文件。這是研究核心如何工作的好起點。
4.mm目錄包含了所有的內存管理代碼。與具體硬體體系結構相關的內存管理代碼位於arch/*/mm目錄下。
5.drivers目錄中是系統中所有的設備驅動程序。它又進一步劃分成幾類設備驅動，每一種有對應的子目錄，如音效卡的驅動對應於drivers/sound。
6.ipc目錄包含了核心進程間的通信代碼。
7.moles目錄存放了已建好的、可動態載入的模塊。
8.fs目錄存放Linux支持的文件系統代碼。不同的文件系統有不同的子目錄對應，如ext3文件系統對應的就是ext3子目錄。
Kernel內核管理的核心代碼放在這里。同時與處理器結構相關代碼都放在arch/*/kernel目錄下。
9.net目錄里是核心的網路部分代碼，其每個子目錄對應於網路的一個方面。
10.lib目錄包含了核心的庫代碼，不過與處理器結構相關的庫代碼被放在arch/*/lib/目錄下。
11.scripts目錄包含用於配置核心的腳本文件。
12.documentation目錄下是一些文檔，是對每個目錄作用的具體說明。
一般在每個目錄下都有一個.depend文件和一個Makefile文件。這兩個文件都是編譯時使用的輔助文件。仔細閱讀這兩個文件對弄清各個文件之間的聯系和依託關系很有幫助。另外有的目錄下還有Readme文件，它是對該目錄下文件的一些說明，同樣有利於對內核源碼的理解。
在閱讀方法或順序上，有縱向與橫向之分。所謂縱向就是順著程序的執行順序逐步進行；所謂橫向，就是按模塊進行。它們經常結合在一起進行。對於Linux啟動的代碼可順著Linux的啟動順序一步步來閱讀；對於像內存管理部分，可以單獨拿出來進行閱讀分析。實際上這是一個反復的過程，不可能讀一遍就理解。
㈦ 如何從linux內核的源碼樹中找到init目錄下的do_mounts.c文件，謝謝了
你都知道路徑了，還要問？？
init目錄下就10幾個文件，還不好找啊？？
你是不是沒有源碼目錄阿，去www.kernel.org去下個內核源碼包，然後解壓；你就有自己的源碼目錄了。
㈧ linux內核源碼詳解
Linux的內核源代碼可以從很多途徑得到。一般來講，在安裝的linux系統下，/usr/src/linux目錄下的東西就是內核源代碼。
對於源代碼的閱讀，要想比較順利，事先最好對源代碼的知識背景有一定的了解。對於linux內核源代碼來講，我認為，基本要求是:1、操作系統的基本知識; 2、對C語言比較熟悉，最好要有匯編語言的知識和GNU C對標准C的擴展的知識的了解。
另外在閱讀之前，還應該知道Linux內核源代碼的整體分布情況。我們知道現代的操作系統一般由進程管理、內存管理、文件系統、驅動程序、網路等組成。看一下Linux內核源代碼就可看出，各個目錄大致對應了這些方面。Linux內核源代碼的組成如下(假設相對於linux目錄):
arch 這個子目錄包含了此核心源代碼所支持的硬體體系結構相關的核心代碼。如對於X86平台就是i386。
include 這個目錄包括了核心的大多數include文件。另外對於每種支持的體系結構分別有一個子目錄。
init 此目錄包含核心啟動代碼。
mm 此目錄包含了所有的內存管理代碼。與具體硬體體系結構相關的內存管理代碼位於arch/-/mm目錄下，如對應於X86的就是arch/i386/mm/fault.c 。
drivers 系統中所有的設備驅動都位於此目錄中。它又進一步劃分成幾類設備驅動，每一種也有對應的子目錄，如音效卡的驅動對應於drivers/sound。
ipc 此目錄包含了核心的進程間通訊代碼。
moles 此目錄包含已建好可動態載入的模塊。
fs Linux支持的文件系統代碼。不同的文件系統有不同的子目錄對應，如ext2文件系統對應的就是ext2子目錄。
kernel 主要核心代碼。同時與處理器結構相關代碼都放在arch/-/kernel目錄下。
net 核心的網路部分代碼。裡面的每個子目錄對應於網路的一個方面。
lib 此目錄包含了核心的庫代碼。與處理器結構相關庫代碼被放在arch/-/lib/目錄下。
scripts 此目錄包含用於配置核心的腳本文件。
Documentation 此目錄是一些文檔，起參考作用。
㈨ 為什麼在linux的3.0.4的源代碼中，找不到kernel、init、fs、mm等目錄
找個你熟悉的函數，用grep -r在源碼樹裡面搜索嘛
㈩ 如何查看 linux 內核源代碼
Linux的內核源代碼可以從很多途徑得到。一般來講，在安裝的linux系統下，/usr/src/linux目錄下的東西就是內核源代碼。
對於源代碼的閱讀，要想比較順利，事先最好對源代碼的知識背景有一定的了解。對於linux內核源代碼來講，我認為，基本要求是:1、操作系統的基本知識;2、對C語言比較熟悉，最好要有匯編語言的知識和GNU C對標准C的擴展的知識的了解。另外在閱讀之前，還應該知道Linux內核源代碼的整體分布情況。我們知道現代的操作系統一般由進程管理、內存管理、文件系統、驅動程序、網路等組成。看一下Linux內核源代碼就可看出，各個目錄大致對應了這些方面。Linux內核源代碼的組成如下(假設相對於linux目錄):
arch 這個子目錄包含了此核心源代碼所支持的硬體體系結構相關的核心代碼。如對於X86平台就是i386。
include 這個目錄包括了核心的大多數include文件。另外對於每種支持的體系結構分別有一個子目錄。
init 此目錄包含核心啟動代碼。
mm 此目錄包含了所有的內存管理代碼。與具體硬體體系結構相關的內存管理代碼位於arch/*/mm目錄下，如對應於X86的就是arch/i386/mm/fault.c 。
drivers 系統中所有的設備驅動都位於此目錄中。它又進一步劃分成幾類設備驅動，每一種也有對應的子目錄，如音效卡的驅動對應於drivers/sound。
ipc 此目錄包含了核心的進程間通訊代碼。
moles 此目錄包含已建好可動態載入的模塊。
fs Linux支持的文件系統代碼。不同的文件系統有不同的子目錄對應，如ext2文件系統對應的就是ext2子目錄。
kernel 主要核心代碼。同時與處理器結構相關代碼都放在arch/*/kernel目錄下。
net 核心的網路部分代碼。裡面的每個子目錄對應於網路的一個方面。
lib 此目錄包含了核心的庫代碼。與處理器結構相關庫代碼被放在arch/*/lib/目錄下。
scripts此目錄包含用於配置核心的腳本文件。
Documentation 此目錄是一些文檔，起參考作用。
俗話說:「工欲善其事，必先利其器」。 閱讀象Linux核心代碼這樣的復雜程序令人望而生畏。它象一個越滾越大的雪球，閱讀核心某個部分經常要用到好幾個其他的相關文件，不久你將會忘記你原來在干什麼。所以沒有一個好的工具是不行的。由於大部分愛好者對於Window平台比較熟悉，並且還是常用Window系列平台，所以在此我介紹一個Window下的一個工具軟體:Source Insight。這是一個有30天免費期的軟體，可以從www.sourcedyn.com下載。安裝非常簡單，和別的安裝一樣，雙擊安裝文件名，然後按提示進行就可以了。安裝完成後，就可啟動該程序。這個軟體使用起來非常簡單，是一個閱讀源代碼的好工具。它的使用簡單介紹如下:先選擇Project菜單下的new，新建一個工程，輸入工程名，接著要求你把欲讀的源代碼加入(可以整個目錄加)後，該軟體就分析你所加的源代碼。分析完後，就可以進行閱讀了。對於打開的閱讀文件，如果想看某一變數的定義，先把游標定位於該變數，然後點擊工具條上的相應選項，該變數的定義就顯示出來。對於函數的定義與實現也可以同樣操作。別的功能在這里就不說了，有興趣的朋友可以裝一個Source Insight，那樣你閱讀源代碼的效率會有很大提高的。怎麼樣，試試吧!