Linux內核啟動(詳細).doc

Linux內核啟動（詳細）在內核成功裝入內存（如果需要就解壓縮）以及一些關鍵硬件，例如已經(jīng)在低層設置過的內存管理器（MMU，請參見第8章）之后，內核將跳轉到start_kernel（19802行）。這個函數(shù)完成其余的系統(tǒng)初始化工作實際上，幾乎所有的初始化工作都是由這個函數(shù)實現(xiàn)的。因此，start_kernel就是本節(jié)的核心。start_kernel19802：_init標示符在gcc編譯器中指定將該函數(shù)置于內核的特定區(qū)域。在內核完成自身初始化之后，就試圖釋放這個特定區(qū)域。實際上，內核中存在兩個這樣的區(qū)域，.text.init和.data.init第一個是代碼初始化使用的，另外一個是數(shù)據(jù)初始化使用的（可以在進程間共享的代碼和字符串常量之類的“文本（Text）”是在可執(zhí)行程序中的“純區(qū)域”中使用的一個術語）。另外你也可以看到_initfunc和_initdata標志，前者和_init類似，標志初始化專用代碼，后者則標志初始化專用數(shù)據(jù)。19807：如前所述，即使在多處理器系統(tǒng)中，在啟動時也只使用一個CPU。Intel稱之為引導程序處理器（bootstrap processor，簡稱為BSP），它在內核代碼的某些地方有時也稱之為BP。BSP首次運行這一行時，跳過后面的if語句，并減小boot_cpu標志，從而當其他CPU運行到此處時，都要運行if語句。等到其他CPU被激活執(zhí)行到這里時，BSP已經(jīng)在idle循環(huán)中了（本章稍后會更詳細地討論這個問題），initialize_secondary（4355行）負責把其他CPU加入到BSP中。這樣，其他CPU就不用執(zhí)行start_kernel的剩余部分了這也是一件好事，因為這意味著不用再對許多硬件進行冗余初始化等工作了。順便說一下，這種奇異的小小的改動只有對于x86是必需的；對于其他平臺，調用smp_init完全可以處理SMP設置的其他部分。因此，其他平臺的initialize_secondary的定義都是空的。19816：打印內核標題信息（20099行），這里顯示了有關內核如何編譯的信息，包括在什么機器上編譯，什么時間編譯，使用什么版本的編譯器，等等。如果中間任何一步發(fā)生了錯誤，在尋找機器不能啟動的原因時查明內核的來源是一個有用的線索。19817：初始化內核自身的部分組件內存、硬件中斷、調度程序，等等。尤其是setup_arch函數(shù)（19765行）完成體系結構相關的設置，此后在command_line（傳遞到內核的參數(shù)，在下面討論）、memory_start和memory_end（內核可用物理地址范圍）中返回結果。下面這些函數(shù)都希望駐留在內存低端，它們使用memory_start和memory_end來傳遞該信息。在函數(shù)獲得所希望的值后，返回值指明了新的memory_start的值。19823：分析傳給內核的各種選項。parse_options函數(shù)（19707行，在隨后的“分析內核選項”一節(jié)中討論）也設置了argv和envp的初值。19833：內核運行過程中也可以自行對所進行的工作進行記錄，周期性地對所執(zhí)行的指令進行抽樣，并使用所獲得的結果更新表格。這在定時器中斷過程中通過調用x86_do_profile（1896行）來實現(xiàn)，該部分將在第6章中介紹。如圖4-1中說明的那樣，這個表格把內核劃分為幾個大小相同的范圍，并簡單跟蹤在一次中斷的時間內每個范圍中運行多少條指令。這種記錄當然是非常粗糙的甚至不是依據(jù)函數(shù)和行號進行劃分的，而只是使用近似的地址但是這樣代價很低，且快速、短小，而且有助于專家判斷最關鍵的問題。每個表格條目所涉及到地址的多少還有問題發(fā)生地點的不確定性可以通過簡單修改prof_shift（26142行）來調節(jié)。profile_setup（19076行，在本章中后面討論）可以讓你在啟動的時候設置prof_shift的值，這樣比為修改這個數(shù)字而重新編譯內核要清晰方便得多。圖4-1 描述用緩存這個if程序塊為記錄表格分配內存，并把所有項都清零。注意到如果prof_shift是0（默認值），那么記錄功能就被關掉了，if程序塊不再被執(zhí)行，也不為表格分配空間。19846：內核通過調用sti（UP版本的13104行，注意該主題在第6章中有更詳細的介紹）開始接收硬件中斷。首先需要激活定時器中斷，以便后來對calibrate_delay（19654行）的調用可以計算機器的BogoMIPS的值（在下一節(jié)“BogoMIPS”中介紹）。因為一些設備驅動程序需要BogoMIPS的值，所以內核必需在大部分硬件、文件系統(tǒng)等等初始化之前計算出這個值來。19876：測試該CPU的各種缺陷，比如Pentium F00F缺陷（請參見第8章），記錄檢測到的缺陷，以便于內核的其他部分以后可以使用它們工作。（為了節(jié)省空間起見，我們省略掉了check_bugs函數(shù)。）19882：調用smp_init（19787行），它又調用了其他的函數(shù)來激活SMP系統(tǒng)中的其他CPU：在x86的平臺上，smp_boot_cpus（4614行）初始化一些內核數(shù)據(jù)結構，這些數(shù)據(jù)結構跟蹤檢測另外的CPU并簡單的將其改為保持模式；最后smp_commence（4195行）使這些CPU繼續(xù)執(zhí)行。19883：把init函數(shù)作為內核線程終止，這比較復雜；請參閱本章后面有關init的討論。19885：增加idle進程的need_resched標志，這樣做的原因此時可能還比較模糊。當讀完了第5、6、7章以后，就會有個清楚的概念；但是，在下一個定時器中斷結束之前（在第6章中討論），system_call（171行，在第5章中討論）函數(shù)中會注意到idle進程的need_resched標志增加了，并且調用schedule（26686行，第7章）釋放CPU，并將其賦給更應該獲取CPU的進程。19886：已經(jīng)完成了內核初始化的工作或者不管怎樣，已經(jīng)把需要完成的少量責任傳遞給了init，所剩余的工作不過是進入idle循環(huán)以消耗空閑的CPU時間片。因此，本行調用cpu_idle（2014行）idle循環(huán)。正如你可以從cpu_idle本身可以發(fā)現(xiàn)的一樣，該函數(shù)從不返回。然而，當有實際工作要處理時，該函數(shù)就會被搶占。注意到cpu_idle只是反復調用idle系統(tǒng)調用（下一章將討論系統(tǒng)調用），它通過sys_idle（2064行）實現(xiàn)真正的idle循環(huán)2014行對應UP版本，2044行針對SMP版本。它們通過執(zhí)行hlt（對應“halt”）指令把CPU轉入低功耗的“睡眠”狀態(tài)。只要沒有實際的工作處理，CPU都將轉入這種狀態(tài)。4.2.1 BogoMIPSBogoMIPS的數(shù)字由內核計算并在系統(tǒng)初始化的時候打印。它近似給出了每秒鐘CPU可以執(zhí)行一個短延遲循環(huán)的次數(shù)。在內核中，這個結果主要用于需要等待非常短周期的設備驅動程序例如，等待幾微秒并查看設備的某些信息是否已經(jīng)可用。由于沒有正確理解BogoMIPS的含義，BogoMIPS在各處都被濫用，就仿佛它可以滿足人類最原始、最深層次的需求：把所有計算機性能的信息簡化為一個數(shù)字?！癇ogoMIPS”中的“Bogo”部分來源于“偽（bogus）”，就正是為了防止這種用法：雖然這個數(shù)字比大多數(shù)基準測試數(shù)大，但是它仍然是不準確的、容易引起誤解的、無用的和不真實的，根本不適合將它用于機器間差別的對比。但是這個數(shù)字仍然非常吸引人，這也正是我們在這里討論這個問題的原因。（BogoMIPS 中“MIPS”部分是“millions of instructions per second（百萬條指令每秒）”的縮寫，這是cpu基準測試中的一個常用單位。）calibrate_delay19654：calibrate_delay是近似計算BogoMIPS數(shù)字的內核函數(shù)。19622：作為第一次估算，calibrate_delay計算出在每一秒內執(zhí)行多少次_delay循環(huán)（6866行），也就是每個定時器滴答（timer tick）百分之一秒內延時循環(huán)可以執(zhí)行多少次。19664：計算一個定時器滴答內可以執(zhí)行多少次循環(huán)需要在滴答開始時就開始計數(shù)，或者應該盡可能與它接近。全局變量jiffies（16588行）中存儲了從內核開始保持跟蹤時間開始到現(xiàn)在已經(jīng)經(jīng)過的定時器滴答數(shù)；第6章中將介紹它的實現(xiàn)方式。jiffies保持異步更新，在一個中斷內每秒一百次，內核暫時掛起正在處理的內容，更新變量，然后繼續(xù)剛才的工作。如果不這樣處理，下一行的循環(huán)就永遠不可能退出。從而，如果jiffies不聲明為volatile簡單地說，這個值變化的原因對于編譯器是透明的，gcc仍然可能對該循環(huán)進行優(yōu)化，并引起該循環(huán)進入不能退出的狀態(tài)。雖然目前的gcc還沒有如此高的智能，然而它的維護者應該完全能夠為它實現(xiàn)這種智能。19669：定時器又前移了一個滴答，因此又產(chǎn)生一個新的滴答。下一步是要等待loops_per_sec延時循環(huán)調用定時器循環(huán)，接著檢測是否最少有一個完整的滴答已經(jīng)完成。如果是這樣，就退出首次近似估算循環(huán)；如果沒有，就把loops_per_sec的值加倍，然后重新啟動這個過程。這個循環(huán)的正確性依賴于如下的事實：現(xiàn)有的機器在任何地方都不能每秒執(zhí)行232次延時循環(huán)（對于64位機來說則遠低于每秒264次)，雖然這只是一個微不足道的問題。19677：現(xiàn)在內核已經(jīng)清楚loops_per_sec循環(huán)調用延時循環(huán)在這臺機器上要花費超過百分之一秒的時間才能完成，因此，內核將重新開始進行估算。為了提高效率，內核使用折半查找算法計算loops_per_sec的實際值，我們假定開始的時候，實際值在現(xiàn)在計算結果和其一半之間實際值不可能比現(xiàn)在計算值還大，但是可以（而且可能）稍微小一點。19681：和前面使用的方式一樣，calibrate_delay查看這個loops_per_sec已經(jīng)減小了的值是否還是比較大，而需要耗費一個完整的定時器間隔。如果還是相當大，實際值應該小于當前計算值或者就是當前值，因此，使用更小的值繼續(xù)查詢；如果不夠大，就使用一個更大的值繼續(xù)查詢。19691：內核有一種很好的方法來計算一個定時器滴答中執(zhí)行延時循環(huán)的次數(shù)。這個數(shù)字乘以一秒內滴答的數(shù)量就得到了每秒內可以執(zhí)行的延時循環(huán)的次數(shù)。這種計算只是一種估算，乘法也累積了誤差，因此結果并不能精確到納秒。但是這個數(shù)字供內核使用已經(jīng)足夠精確了。19693：為了讓用戶感到激動，內核打印出這個數(shù)字。注意這里明顯省略了%f的格式限定內核盡量避免浮點數(shù)運算。這個計算過程中最有用的常量是500 000；它是用一百萬除以2得來，理由是每秒鐘執(zhí)行一百萬條指令，而每個delay循環(huán)的核心是2條指令（decl和一條跳轉指令）。4.2.2 分析內核選項parse_options函數(shù)分析由內核引導程序發(fā)送給內核的啟動選項，在初始化過程中按照某些選項運行，并將剩余部分傳送給init進程（在本章后面部分提到）。這些選項可能已經(jīng)存儲在配置文件中了，也可能是由用戶在系統(tǒng)啟動時敲入的內核并不關心這些。類似的細節(jié)全部是內核引導程序應該關注的內容。1. parse_options19707：參數(shù)已經(jīng)收集在一條長的命令行中，內核被賦給指向該命令行頭部的一個指針；內核引導程序在前面已經(jīng)將該行存儲在一個指定地址中。19718：中斷下一個參數(shù)，保持指向下一個參數(shù)的指針以供下一次循環(huán)使用。注意系統(tǒng)使用空格而不是通常的空白來分隔內核參數(shù)；制表符并不能把當前參數(shù)和下一個參數(shù)分隔開。如果發(fā)現(xiàn)了分隔字符空格，下一行就使用字節(jié)0覆蓋，這樣line可以作為包含有唯一一個內核選項的標準C字符串來使用了。如果沒有發(fā)現(xiàn)空格，就該函數(shù)關心的內容而言，其余的部分都具有相同的屬性這只有在處理line中最后一個選項的情況下才會發(fā)生，循環(huán)就會在下次開始時結束。注意該代碼不會跳過多個空格。假設line值如下所述（兩個空格）：rw debug這會被當作三個選項：“rw”、“”（空字符串）和“debug”。因為空字符串不是有效的內核選項，它將會被傳遞到初始化的過程（這一點隨后就可以看到）這當然不是用戶所希望的。因此，內核引導程序應該負責對多個空格進行壓縮。LILO通過忽略用戶多敲的空格，完美地解決了這個問題。19721：現(xiàn)在開始解釋這些選項。最前面的兩個選項ro和rw指明內核要裝載根文件系統(tǒng)，也就是根目錄（ / 目錄）所在的位置，而分別處于只讀和讀/寫模式。19729：第三種可能性，debug，增加了調試信息的數(shù)量；這些調試信息要通過調用do_syslog打印出來（25724行）。19733：開始幾個選項是簡單的獨立標志，它們并不使用參數(shù)。內核也可以辨認形為option=value的選項。本行就是一個例子，這里內核引導程序定義了一個命令來代替init運行；它使用init=/some/other/program的形式。這里的代碼舍棄了init= 部分，為隨后init的使用而把剩余部分在execute_command中保存起來（20044行）。和其他大部分參數(shù)的處理方法不同，本處功能不能在checksetup（19612行）中實現(xiàn)，這是因為它改變了該函數(shù)的局部變量。很快，你就可以看到前面三個選項之所以也在這里處理，而不是在checksetup中處理的原因。19745：大部分內核選項都是由checksetup函數(shù)分析的。如果checksetup處理了某個選項，就返回真值，循環(huán)繼續(xù)進行。19750：否則，line中沒有已經(jīng)被辨認的內核選項。在這種情況下，它被作為一個供init進程使用的選項或者環(huán)境變量來處理如果其形式為envar=value，就作為環(huán)境變量處理；否則，就作為選項處理。如果argv_init和envp_init（分別見19057和19059行）數(shù)組中有足夠的空間，選項和環(huán)境變量就存儲在里面供以后init函數(shù)使用。這解釋了從19736行開始的注釋。字符串a(chǎn)uto并不是任何內核選項的前綴，因此它應該被作為init的一個參數(shù)存儲在argv_init數(shù)組中這在大多數(shù)情況下都是可行的，因為auto是init可以識別的選項。但是，當使用init=的形式給出內核選項時，通常是執(zhí)行shell而不是init，auto會使shell混淆；因此，安全一點的方法是，parse_options在此處忽略所有與此有關的init參數(shù)。奇怪的是，當argv_init或者envp_init數(shù)組空間用完時，整個循環(huán)就結束了。僅僅因為argv_init的空間用完了并不意味著line中就不再含有init使用的環(huán)境變量，反之亦然。此外，可能還剩下許多內核選項沒有處理。當你考慮到MAX_INIT_ARGS（19029行）和MAX_INIT_ENVS（19030行）都通過使用#define被預定義為8這是一個很容易超過的下限，這種行為就更奇怪了。如果在19752行和19756行的break改成continue，那么循環(huán)可以繼續(xù)處理內核選項，而不會寫入超過argv_init和envp_init數(shù)組界限的空間。如果command_line中仍然包含有并不是為init而定義的內核選項，那么這一點就是非常重要的。19760：所有的內核選項都處理完成了。最后一步是要使用NULL填充argv_init和envp_init數(shù)組的末尾，從而使得init可以知道在哪里終止。2. checksetup19612：checksetup函數(shù)負責進行大部分內核選項的處理過程。它把這些內核選項分為三類：一類使用內核普通參數(shù)來分析=sign之后的部分；另一類自行分析=sign之后的部分；還有一類自行分析整個行，包括= sign前面的部分和= sign后面的部分。第一類被認為是使用“現(xiàn)成”的參數(shù)，這與為第二類提供的“原始”參數(shù)相對應。最后一類只由一個IDE驅動程序組成；內核首先在19619行檢查并處理這種情況，以使其不會在隨后的處理中造成麻煩。19625：接下來，checksetup掃描整個raw_params數(shù)組（19552行）,并判斷是否該內核選項應該不加處理地保留。raw_params中的元素是struct kernel_param類型（19223行）的，它把內核選項前綴和裝載選項時調用的函數(shù)聯(lián)系起來。如果數(shù)組中的某些項的str成員以line為前綴，就會調用line后面的相應函數(shù)（也就是前綴之后的部分），隨后checksetup會返回一個非零值以表明它已經(jīng)對該內核選項進行了處理。raw_params數(shù)組以兩個NULL結束，因此在檢測到str成員是NULL時，循環(huán)就可以結束了。在這種情況下，顯然循環(huán)已經(jīng)到達了raw_params數(shù)組的結尾，但是仍然沒有找到匹配的情況。當然，測試setup_func成員也可以取得同樣好的效果。這個循環(huán)說明了一點：與大多數(shù)內核非常不同的是，這里的初始化并不需要盡可能地快。如果內核比從前多用幾微秒來啟動，這并沒有什么實際的損失畢竟用戶應用程序還沒有開始運行，所以他們并沒有損失什么東西。最終結果是代碼效率很低，而且存在很多優(yōu)化的可能。例如，raw_params數(shù)組中字符串的長度可以在raw_params中暫存，而不用在19626行多次重復計算。更好的解決方法是，可以把raw_params數(shù)組中的項按照字符順序排序，這樣checksetup就可以進行折半查找。在raw_params的情況中實現(xiàn)排序并沒有什么障礙，但是這樣也可能并不能獲得很大的優(yōu)勢，因為折半查找的優(yōu)點只有在比較大的數(shù)組中才能充分表現(xiàn)出來（所謂比較大的確切值在不同的環(huán)境中也有所不同）。raw_params的姊妹數(shù)組cooked_params（19228行）當然是足夠大的，可以顯示出折半查找的優(yōu)勢；但是這樣就引發(fā)了一個新的問題：對cooked_params進行排序比較難用，因為這可能需要分隔一些#ifdef程序段請參看從19268行到19272行的例子。進一步說，因為算法只是查找前綴，而不使用完全匹配，在遍歷數(shù)組中的各個項時對遍歷次序比較敏感，所以這種特性在使用不同的查找次序時就很難再保持了。然而，這些問題并不是不可克服的（程序員可以預先靜態(tài)地為引導程序建立一顆前綴樹），如果性能在這里是主要因素，那么這種努力也是值得的。但是，由于性能在這里并不是主要問題，所以簡單性才被作為最重要的因素體現(xiàn)出來。即使這樣，在類似的root_dev_names數(shù)組（19085行）中這個數(shù)組把硬件設備名的前綴映射到它們的主ID號上，開發(fā)者仍然可以簡單地通過把比較常用的項（IDE和SCSI磁盤）放在不太常用的項（并口IDE CD）的前面以節(jié)省出一點性能。但是我在raw_params或cooked_params中并沒有發(fā)現(xiàn)與之類似的模式。另外一件需要注意的事是：現(xiàn)在你可以猜想一下為什么ro、rw和debug選項在parse_options中測試而不在這里測試，parse_options要檢測精確的匹配，但是checksetup只檢測前綴。作為一個特殊的情況，ro選項碰巧正好是root=（19553行）的前綴，這樣如果這三個選項彼此合并，就需要仔細處理了。這似乎仍然是一個相當無力的原因。考慮一下noinitrd選項（19251行）。這是cooked_params的一個項，因而只需要匹配前綴，而且與之相關聯(lián)的設置函數(shù)（no_initrd，19902行）將忽略所有可能已經(jīng)傳遞給它們的參數(shù)這正像ro、rw和debug被包含在cooked_params中時所可能進行的工作一樣。19632：這個循環(huán)為cooked_params數(shù)組的處理工作和前面一個循環(huán)為raw_params數(shù)組的處理工作相同。這兩個循環(huán)（當然不包括循環(huán)使用的數(shù)組）間的唯一區(qū)別是本循環(huán)在調用設置函數(shù)之前，使用get_options（19062行）處理line中=sign后面的部分。簡單地說，get_options使用10個負整數(shù)填充ints1到s0中是ints中使用元素的個數(shù)也就是，它記錄了存儲在ints中的ints get_options數(shù)量。接著這個數(shù)組將被傳遞給設置函數(shù)，該設置函數(shù)則會按照自己喜歡的方式對該數(shù)組內容進行解釋。19640：返回0，說明line中所包含的內核選項不能被函數(shù)理解。3. profile_setup19076：profile_setup是checksetup調用的設置函數(shù)的一個完美的例子：這個函數(shù)十分短小，使用ints參數(shù)處理了部分內容。而且到目前為止你也應該對它的目的有了一定了解。正如前面提到的一樣，用戶可以在啟動的時候設置prof_shift的值這里正是它的實現(xiàn)方式。當內核啟動過程提供profile=選項時，就調用profile_setup函數(shù)。前綴字符串和函數(shù)在19235行被聯(lián)系在一起。注意這是在cooked_params中，因此profile_setup取得的是處理過的參數(shù)。19079：如果參數(shù)中存在profile=的形式，就使用profile=后面的第一個數(shù)字作為prof_shift的新值。選項給出的其他參數(shù)都被簡單地忽略了。19081：如果給出了profile=選項，但是沒有為它提供參數(shù)，prof_shift的缺省值就是2。這個缺省值有些奇怪，因為我們已經(jīng)知道，這意味著使用四分之一的內核可用內存來配置其余部分這是一個很大的開銷。但是另一方面，使用這些內存有助于更精確地定位問題熱點只有很少的幾條指令存在不確定性，這樣應該比較容易地把問題限制在一兩行源程序代碼內。那張圖也并不是像我所畫的那樣簡單：因為圖中只描述了內核代碼，這種開銷還不到內核所有內存空間的25%，但是對于所覆蓋的代碼量來說卻并不止25%。4.3 initinit從許多方面看都是一個非常特殊的進程。這是內核運行的第一個用戶進程，它要負責觸發(fā)其他必需的進程以使系統(tǒng)作為一個整體進入可用的狀態(tài)。這些工作由/etc/inittab文件控制，通常包括設置getty進程以接受用戶登錄，建立網(wǎng)絡服務，例如FTP和HTTP守護進程，等等。如果沒有這些進程，用戶就不可能完成很多工作，這樣成功啟動內核就顯得沒有多大意義了。這種設計的另外一個主要的副作用是init是系統(tǒng)中所有進程的祖先。init產(chǎn)生getty進程，getty進程產(chǎn)生login進程，login進程產(chǎn)生你自己的shell，使用自己的shell，可以產(chǎn)生每一個你運行的進程。在所有的結果中，這有助于確保內核進程表中的所有項最終都能夠得到處理。進程結束以后將其清除（回收）的工作首先應由其父進程完成；如果父進程已經(jīng)退出，那么祖父進程就要擔負起這種責任；如果祖父進程已經(jīng)退出，那么曾祖父進程就要擔負起這種責任，周而復始。通過這種方式，從不退出的init進程就可能要負責回收其他進程。因此，為了確保這些重要的工作都能正確執(zhí)行，內核初始化進程所需要做的最后一步工作就是創(chuàng)建init進程，接下來就加以描述。init20044：unused參數(shù)來源于該函數(shù)的非常規(guī)調用。init函數(shù)不要和init進程搞混了，后者是它隨后要創(chuàng)建的作為內核線程開始生命周期，一個作為內核的一部分運行的進程（如果你編寫過多線程的程序，這里的內核線程可能會同你所已經(jīng)知道的線程意義有所不同在那種意義下，它不是一個內核線程）。實際上，init函數(shù)就像是新進程使用的剝離出來了的main函數(shù)，unused參數(shù)是一個獨立的指針，其值指向為給定進程所提供的信息這比通常使用argc、argv和envp參數(shù)傳遞的信息要少得多。init函數(shù)碰巧不需要額外的信息，這個參數(shù)命名為unused，就是要強調這一點。為了確保在這一點上你不會產(chǎn)生困惑，我們在這里再對整個機制進行扼要重復：init函數(shù)是內核的一部分；它在內核中作為內核的一個獨立的執(zhí)行部分運行；也就是說，無論從哪個方面看它都是內核代碼。但是，init進程就不是這樣了。在某些方面，init進程是一個特殊的進程，但是不屬于內核本身；其代碼存儲在磁盤上單獨的可執(zhí)行映像中，這和其他程序一樣。因為init函數(shù)后來產(chǎn)生init進程，而它自己又恰好作為進程運行，這樣就很容易產(chǎn)生混淆。因為idle進程已經(jīng)占據(jù)了進程ID號（PID）0，init（當然是init）就被賦值為下一個可用的PID，也就是1（進程ID在第7章中討論）。內核重復假定PID為1的進程是init，因此這種特性在