linux啓動過程

　內容：

　　一. Bootloader
　　二.Kernel引導入口
　　三.核心數據結構初始化--內核引導第一部分
　　四.外設初始化--內核引導第二部分
　　五.init進程和inittab引導指令
　　六.rc啓動腳本
　　七.getty和login
　　八.bash
　　附：XDM方式登陸

　　本文以Redhat 6.0 Linux 2.2.19 for Alpha/AXP爲平臺，描述了從開機到登陸的 Linux 啓動全過程。該文對i386平臺一樣適用。
　　一. Bootloader
在Alpha/AXP平臺上引導Linux一般有兩種方法，一種是由MILO及其餘相似的引導程序引 導，另外一種是由Firmware直接引導。MILO功能與i386平臺的LILO相近，但內置有基本的磁盤 驅動程序（如IDE、SCSI等），以及常見的文件系統驅動程序（如ext2，iso9660等）， firmware有ARC、SRM兩種形式，ARC具備類BIOS界面，甚至還有多重引導的設置；而SRM則具 有功能強大的命令行界面，用戶能夠在控制檯上使用boot等命令引導系統。ARC有分區 （Partition）的概念，所以能夠訪問到分區的首扇區；而SRM只能將控制轉給磁盤的首扇區。 兩種firmware均可以經過引導MILO來引導Linux，也能夠直接引導Linux的引導代碼。

「arch/alpha/boot」下就是製做Linux Bootloader的文件。「head.S」文件提供了對 OSF PAL/1的調用入口，它將被編譯後置於引導扇區（ARC的分區首扇區或SRM的磁盤0扇區）， 獲得控制後初始化一些數據結構，再將控制轉給「main.c」中的start_kernel()， start_kernel()向控制檯輸出一些提示，調用pal_init()初始化PAL代碼，調用openboot() 打開引導設備（經過讀取Firmware環境），調用load()將核心代碼加載到START_ADDR（見 「include/asm-alpha/system.h」），再將Firmware中的核心引導參數加載到ZERO_PAGE(0) 中，最後調用runkernel()將控制轉給0x100000的kernel，bootloader部分結束。

「arch/alpha/boot/bootp.c」以「main.c」爲基礎，可代替「main.c」與「head.S」 生成用於BOOTP協議網絡引導的Bootloader。
Bootloader中使用的全部「srm_」函數在「arch/alpha/lib/」中定義。

以上這種Boot方式是一種最簡單的方式，即不需其餘工具就能引導Kernel，前提是按照 Makefile的指導，生成bootp_w_picpath文件，內含以上提到的bootloader以及vmlinux，而後將 bootp_w_picpath寫入自磁盤引導扇區始的位置中。

當採用MILO這樣的引導程序來引導Linux時，不須要上面所說的Bootloader，而只須要 vmlinux或vmlinux.gz，引導程序會主動解壓加載內核到0x1000（小內核）或0x100000（大 內核），並直接進入內核引導部分，即本文的第二節。

對於I386平臺
i386系統中通常都有BIOS作最初的引導工做，那就是將四個主分區表中的第一個可引導 分區的第一個扇區加載到實模式地址0x7c00上，而後將控制轉交給它。

在「arch/i386/boot」目錄下，bootsect.S是生成引導扇區的彙編源碼，它首先將本身 拷貝到0x90000上，而後將緊接其後的setup部分（第二扇區）拷貝到0x90200，將真正的內核 代碼拷貝到0x100000。以上這些拷貝動做都是以bootsect.S、setup.S以及vmlinux在磁盤上 連續存放爲前提的，也就是說，咱們的bzImage文件或者zImage文件是按照bootsect，setup， vmlinux這樣的順序組織，並存放於始於引導分區的首扇區的連續磁盤扇區之中。

bootsect.S完成加載動做後，就直接跳轉到0x90200，這裏正是setup.S的程序入口。 setup.S的主要功能就是將系統參數（包括內存、磁盤等，由BIOS返回）拷貝到 0x90000-0x901FF內存中，這個地方正是bootsect.S存放的地方，這時它將被系統參數覆蓋。 之後這些參數將由保護模式下的代碼來讀取。

除此以外，setup.S還將video.S中的代碼包含進來，檢測和設置顯示器和顯示模式。最 後，setup.S將系統轉換到保護模式，並跳轉到0x100000（對於bzImage格式的大內核是 0x100000，對於zImage格式的是0x1000）的內核引導代碼，Bootloader過程結束。

對於2.4.x版內核
沒有什麼變化。

　　二.Kernel引導入口

在arch/alpha/vmlinux.lds的連接腳本控制下，連接程序將vmlinux的入口置於 "arch/alpha/kernel/head.S"中的__start上，所以當Bootloader跳轉到0x100000時， __start處的代碼開始執行。__start的代碼很簡單，只須要設置一下全局變量，而後就跳轉 到start_kernel去了。start_kernel()是"init/main.c"中的asmlinkage函數，至此，啓 動過程轉入體系結構無關的通用C代碼中。

對於I386平臺
在i386體系結構中，由於i386自己的問題，在"arch/alpha/kernel/head.S"中須要更多的設置，但最終也是經過call SYMBOL_NAME(start_kernel)轉到start_kernel()這個體系結構無關的函數中去執行了。

所不一樣的是，在i386系統中，當內核以bzImage的形式壓縮，即大內核方式 （__BIG_KERNEL__）壓縮時就須要預先處理bootsect.S和setup.S，按照大核模式使用$(CPP) 處理生成bbootsect.S和bsetup.S，而後再編譯生成相應的.o文件，並使用 "arch/i386/boot/compressed/build.c"生成的build工具，將實際的內核（未壓縮的，含 kernel中的head.S代碼）與"arch/i386/boot/compressed"下的head.S和misc.c合成到一塊兒，其中的head.S代替了"arch/i386/kernel/head.S"的位置，由Bootloader引導執行 （startup_32入口），而後它調用misc.c中定義的decompress_kernel()函數，使用 "lib/inflate.c"中定義的gunzip()將內核解壓到0x100000，再轉到其上執行 "arch/i386/kernel/head.S"中的startup_32代碼。

對於2.4.x版內核
沒有變化。

　　三.核心數據結構初始化--內核引導第一部分
start_kernel()中調用了一系列初始化函數，以完成kernel自己的設置。 這些動做有的是公共的，有的則是須要配置的纔會執行的。

在start_kernel()函數中，
輸出Linux版本信息（printk(linux_banner)）
設置與體系結構相關的環境（setup_arch()）
頁表結構初始化（paging_init()）
使用"arch/alpha/kernel/entry.S"中的入口點設置系統自陷入口（trap_init()）
使用alpha_mv結構和entry.S入口初始化系統IRQ（init_IRQ()）
核心進程調度器初始化（包括初始化幾個缺省的Bottom-half，sched_init()）
時間、定時器初始化（包括讀取CMOS時鐘、估測主頻、初始化定時器中斷等，time_init()）
提取並分析核心啓動參數（從環境變量中讀取參數，設置相應標誌位等待處理，（parse_options()）
控制檯初始化（爲輸出信息而先於PCI初始化，console_init()）
剖析器數據結構初始化（prof_buffer和prof_len變量）
核心Cache初始化（描述Cache信息的Cache，kmem_cache_init()）
延遲校準（得到時鐘jiffies與CPU主頻ticks的延遲，calibrate_delay()）
內存初始化（設置內存上下界和頁表項初始值，mem_init()）
建立和設置內部及通用cache（"slab_cache"，kmem_cache_sizes_init()）
建立uid taskcount SLAB cache（"uid_cache"，uidcache_init()）
建立文件cache（"files_cache"，filescache_init()）
建立目錄cache（"dentry_cache"，dcache_init()）
建立與虛存相關的cache（"vm_area_struct"，"mm_struct"，vma_init()）
塊設備讀寫緩衝區初始化（同時建立"buffer_head"cache用戶加速訪問，buffer_init()）
建立頁cache（內存頁hash表初始化，page_cache_init()）
建立信號隊列cache（"signal_queue"，signals_init()）
初始化內存inode表（inode_init()）
建立內存文件描述符表（"filp_cache"，file_table_init()）
檢查體系結構漏洞（對於alpha，此函數爲空，check_bugs()）
SMP機器其他CPU（除當前引導CPU）初始化（對於沒有配置SMP的內核，此函數爲空，smp_init()）
啓動init過程（建立第一個核心線程，調用init()函數，原執行序列調用cpu_idle() 等待調度，init()）
至此start_kernel()結束，基本的核心環境已經創建起來了。

對於I386平臺
i386平臺上的內核啓動過程與此基本相同，所不一樣的主要是實現方式。

對於2.4.x版內核
2.4.x中變化比較大，但基本過程沒變，變更的是各個數據結構的具體實現，好比Cache。

　　四.外設初始化--內核引導第二部分
init()函數做爲核心線程，首先鎖定內核（僅對SMP機器有效），而後調用 do_basic_setup()完成外設及其驅動程序的加載和初始化。過程以下：

總線初始化（好比pci_init()）
網絡初始化（初始化網絡數據結構，包括sk_init()、skb_init()和proto_init()三部分，在proto_init()中，將調用protocols結構中包含的全部協議的初始化過程，sock_init()）
建立bdflush核心線程（bdflush()過程常駐核心空間，由核心喚醒來清理被寫過的內存緩衝區，當bdflush()由kernel_thread()啓動後，它將本身命名爲kflushd）
建立kupdate核心線程（kupdate()過程常駐核心空間，由核心按時調度執行，將內存緩衝區中的信息更新到磁盤中，更新的內容包括超級塊和inode表）
設置並啓動核心調頁線程kswapd（爲了防止kswapd啓動時將版本信息輸出到其餘信息中間，核心線調用kswapd_setup()設置kswapd運行所要求的環境，而後再建立 kswapd核心線程）
建立事件管理核心線程（start_context_thread()函數啓動context_thread()過程，並重命名爲keventd）
設備初始化（包括並口parport_init()、字符設備chr_dev_init()、塊設備 blk_dev_init()、SCSI設備scsi_dev_init()、網絡設備net_dev_init()、磁盤初始化及分區檢查等等，device_setup()）
執行文件格式設置（binfmt_setup()）
啓動任何使用__initcall標識的函數（方便核心開發者添加啓動函數，do_initcalls()）
文件系統初始化（filesystem_setup()）
安裝root文件系統（mount_root()）
至此do_basic_setup()函數返回init()，在釋放啓動內存段（free_initmem()）並給內核解鎖之後，init()打開/dev/console設備，重定向stdin、stdout和stderr到控制檯，最後，搜索文件系統中的init程序（或者由init=命令行參數指定的程序），並使用 execve()系統調用加載執行init程序。

init()函數到此結束，內核的引導部分也到此結束了，這個由start_kernel()建立的第一個線程已經成爲一個用戶模式下的進程了。此時系統中存在着六個運行實體：

start_kernel()自己所在的執行體，這實際上是一個"手工"建立的線程，它在建立了init()線程之後就進入cpu_idle()循環了，它不會在進程（線程）列表中出現
init線程，由start_kernel()建立，當前處於用戶態，加載了init程序
kflushd核心線程，由init線程建立，在覈心態運行bdflush()函數
kupdate核心線程，由init線程建立，在覈心態運行kupdate()函數
kswapd核心線程，由init線程建立，在覈心態運行kswapd()函數
keventd核心線程，由init線程建立，在覈心態運行context_thread()函數

對於I386平臺
基本相同。

對於2.4.x版內核
這一部分的啓動過程在2.4.x內核中簡化了很多，缺省的獨立初始化過程只剩下網絡 （sock_init()）和建立事件管理核心線程，而其餘所須要的初始化都使用__initcall()宏 包含在do_initcalls()函數中啓動執行。

　　五.init進程和inittab引導指令
init進程是系統全部進程的起點，內核在完成核內引導之後，即在本線程（進程）空 間內加載init程序，它的進程號是1。

init程序須要讀取/etc/inittab文件做爲其行爲指針，inittab是以行爲單位的描述性（非執行性）文本，每個指令行都具備如下格式：

id:runlevel:action:process其中id爲入口標識符，runlevel爲運行級別，action爲動做代號，process爲具體的執行程序。

id通常要求4個字符之內，對於getty或其餘login程序項，要求id與tty的編號相同，不然getty程序將不能正常工做。

runlevel是init所處於的運行級別的標識，通常使用0－6以及S或s。0、一、6運行級別被系統保留，0做爲shutdown動做，1做爲重啓至單用戶模式，6爲重啓；S和s意義相同，表示單用戶模式，且無需inittab文件，所以也不在inittab中出現，實際上，進入單用戶模式時，init直接在控制檯（/dev/console）上運行/sbin/sulogin。

在通常的系統實現中，都使用了二、三、四、5幾個級別，在Redhat系統中，2表示無NFS支持的多用戶模式，3表示徹底多用戶模式（也是最經常使用的級別），4保留給用戶自定義，5表示XDM圖形登陸方式。7－9級別也是可使用的，傳統的Unix系統沒有定義這幾個級別。runlevel能夠是並列的多個值，以匹配多個運行級別，對大多數action來講，僅當runlevel與當前運行級別匹配成功纔會執行。

initdefault是一個特殊的action值，用於標識缺省的啓動級別；當init由核心激活 之後，它將讀取inittab中的initdefault項，取得其中的runlevel，並做爲當前的運行級 別。若是沒有inittab文件，或者其中沒有initdefault項，init將在控制檯上請求輸入 runlevel。

sysinit、boot、bootwait等action將在系統啓動時無條件運行，而忽略其中的runlevel，其他的action（不含initdefault）都與某個runlevel相關。各個action的定義在inittab的man手冊中有詳細的描述。

在Redhat系統中，通常狀況下inittab都會有以下幾項：
id:3:initdefault:
#表示當前缺省運行級別爲3--徹底多任務模式；
si::sysinit:/etc/rc.d/rc.sysinit
#啓動時自動執行/etc/rc.d/rc.sysinit腳本
l3:3:wait:/etc/rc.d/rc 3
#當運行級別爲3時，以3爲參數運行/etc/rc.d/rc腳本，init將等待其返回
0:12345:respawn:/sbin/mingetty tty0
#在1－5各個級別上以tty0爲參數執行/sbin/mingetty程序，打開tty0終端用於
#用戶登陸，若是進程退出則再次運行mingetty程序
x:5:respawn:/usr/bin/X11/xdm -nodaemon
#在5級別上運行xdm程序，提供xdm圖形方式登陸界面，並在退出時從新執行

　　六.rc啓動腳本
上一節已經提到init進程將啓動運行rc腳本，這一節將介紹rc腳本具體的工做。

通常狀況下，rc啓動腳本都位於/etc/rc.d目錄下，rc.sysinit中最多見的動做就是激活交換分區，檢查磁盤，加載硬件模塊，這些動做不管哪一個運行級別都是須要優先執行的。僅當rc.sysinit執行完之後init纔會執行其餘的boot或bootwait動做。

若是沒有其餘boot、bootwait動做，在運行級別3下，/etc/rc.d/rc將會獲得執行，命令行參數爲3，即執行/etc/rc.d/rc3.d/目錄下的全部文件。rc3.d下的文件都是指向/etc/rc.d/init.d/目錄下各個Shell腳本的符號鏈接，而這些腳本通常能接受start、stop、restart、status等參數。rc腳本以start參數啓動全部以S開頭的腳本，在此以前，若是相應的腳本也存在K打頭的連接，並且已經處於運行態了（以/var/lock/subsys/下的文件做爲標誌），則將首先啓動K開頭的腳本，以stop做爲參數中止這些已經啓動了的服務，而後再從新運行。顯然，這樣作的直接目的就是當init改變運行級別時，全部相關的服務都將重啓，即便是同一個級別。

rc程序執行完畢後，系統環境已經設置好了，下面就該用戶登陸系統了。

　　七.getty和login
在rc返回後，init將獲得控制，並啓動mingetty（見第五節）。mingetty是getty的簡化，不能處理串口操做。getty的功能通常包括：

打開終端線，並設置模式
輸出登陸界面及提示，接受用戶名的輸入
以該用戶名做爲login的參數，加載login程序
缺省的登陸提示記錄在/etc/issue文件中，但每次啓動，通常都會由rc.local腳本根據系統環境從新生成。

注：用於遠程登陸的提示信息位於/etc/issue.net中。

login程序在getty的同一個進程空間中運行，接受getty傳來的用戶名參數做爲登陸的用戶名。

若是用戶名不是root，且存在/etc/nologin文件，login將輸出nologin文件的內容，而後退出。這一般用來系統維護時防止非root用戶登陸。

只有/etc/securetty中登記了的終端才容許root用戶登陸，若是不存在這個文件，則root能夠在任何終端上登陸。/etc/usertty文件用於對用戶做出附加訪問限制，若是不存在這個文件，則沒有其餘限制。

當用戶登陸經過了這些檢查後，login將搜索/etc/passwd文件（必要時搜索 /etc/shadow文件）用於匹配密碼、設置主目錄和加載shell。若是沒有指定主目錄，將默認爲根目錄；若是沒有指定shell，將默認爲/bin/sh。在將控制轉交給shell之前， getty將輸出/var/log/lastlog中記錄的上次登陸系統的信息，而後檢查用戶是否有新郵件（/usr/spool/mail/{username}）。在設置好shell的uid、gid，以及TERM，PATH 等環境變量之後，進程加載shell，login的任務也就完成了。

　　八.bash
運行級別3下的用戶login之後，將啓動一個用戶指定的shell，如下以/bin/bash爲例繼續咱們的啓動過程。

bash是Bourne Shell的GNU擴展，除了繼承了sh的全部特色之外，還增長了不少特性和功能。由login啓動的bash是做爲一個登陸shell啓動的，它繼承了getty設置的TERM、PATH等環境變量，其中PATH對於普通用戶爲"/bin:/usr/bin:/usr/local/bin"，對於root 爲"/sbin:/bin:/usr/sbin:/usr/bin"。做爲登陸shell，它將首先尋找/etc/profile 腳本文件，並執行它；而後若是存在~/.bash_profile，則執行它，不然執行 ~/.bash_login，若是該文件也不存在，則執行~/.profile文件。而後bash將做爲一個交互式shell執行~/.bashrc文件（若是存在的話），不少系統中，~/.bashrc都將啓動 /etc/bashrc做爲系統範圍內的配置文件。

當顯示出命令行提示符的時候，整個啓動過程就結束了。此時的系統，運行着內核，運行着幾個核心線程，運行着init進程，運行着一批由rc啓動腳本激活的守護進程（如 inetd等），運行着一個bash做爲用戶的命令解釋器。

　　附：XDM方式登陸
若是缺省運行級別設爲5，則系統中不光有1-6個getty監聽着文本終端，還有啓動了一個XDM的圖形登陸窗口。登陸過程和文本方式差很少，也須要提供用戶名和口令，XDM 的配置文件缺省爲/usr/X11R6/lib/X11/xdm/xdm-config文件，其中指定了 /usr/X11R6/lib/X11/xdm/xsession做爲XDM的會話描述腳本。登陸成功後，XDM將執行這個腳本以運行一個會話管理器，好比gnome-session等。

除了XDM之外，不一樣的窗口管理系統（如KDE和GNOME）都提供了一個XDM的替代品，如gdm和kdm，這些程序的功能和XDM都差很少。