?? 00000012.htm
字號:
<HTML><HEAD> <TITLE>BBS水木清華站∶精華區</TITLE></HEAD><BODY><CENTER><H1>BBS水木清華站∶精華區</H1></CENTER>發信人: axp33a (無聊中...), 信區: Linux <BR>標 題: Linux內核源代碼分析4-2-1 <BR>發信站: BBS 水木清華站 (Thu Aug 3 11:30:41 2000) WWW-POST <BR> <BR>4.2 初始化Linux內核
<BR>在內核成功裝入內存（如果需要就解壓縮）以及一些關鍵硬件，例如已經在低層設置過的 <BR>內存管理器（MMU，請參見第8章）之后，內核將跳轉到start_kernel（19802行）。這個 <BR>函數完成其余的系統初始化工作—實際上，幾乎所有的初始化工作都是由這個函數實現的 <BR>。因此，start_kernel就是本節的核心。
<BR> start_kernel
<BR>19802：__init標示符在gcc編譯器中指定將該函數置于內核的特定區域。在內核完成自身 <BR>初始化之后，就試圖釋放這個特定區域。實際上，內核中存在兩個這樣的區域， <BR>.text.init和.data.init—第一個是代碼初始化使用的，另外一個是數據初始化使用的（ <BR>可以在進程間共享的代碼和字符串常量之類的“文本（Text）”是在可執行程序中的“純 <BR>區域”中使用的一個術語）。另外你也可以看到__initfunc和__initdata標志，前者和 <BR>__init類似，標志初始化專用代碼，后者則標志初始化專用數據。
<BR>19807：如前所述，即使在多處理器系統中，在啟動時也只使用一個CPU。Intel稱之為引 <BR>導程序處理器（bootstrap processor，簡稱為BSP），它在內核代碼的某些地方有時也稱 <BR>之為BP。BSP首次運行這一行時，跳過后面的if語句，并減小boot_cpu標志，從而當其他 <BR>CPU運行到此處時，都要運行if語句。等到其他CPU被激活執行到這里時，BSP已經在idle <BR>循環中了（本章稍后會更詳細地討論這個問題），initialize_secondary（4355行）負責 <BR>把其他CPU加入到BSP中。這樣，其他CPU就不用執行start_kernel的剩余部分了—這也是 <BR>一件好事，因為這意味著不用再對許多硬件進行冗余初始化等工作了。
<BR>順便說一下，這種奇異的小小的改動只有對于x86是必需的；對于其他平臺，調用 <BR>smp_init完全可以處理SMP設置的其他部分。因此，其他平臺的initialize_secondary的 <BR>定義都是空的。
<BR>19816：打印內核標題信息（20099行），這里顯示了有關內核如何編譯的信息，包括在什 <BR>么機器上編譯，什么時間編譯，使用什么版本的編譯器，等等。如果中間任何一步發生了 <BR>錯誤，在尋找機器不能啟動的原因時查明內核的來源是一個有用的線索。
<BR>19817：初始化內核自身的部分組件—內存、硬件中斷、調度程序，等等。尤其是 <BR>setup_arch函數（19765行）完成體系結構相關的設置，此后在command_line（傳遞到內 <BR>核的參數，在下面討論）、memory_start和memory_end（內核可用物理地址范圍）中返回 <BR>結果。下面這些函數都希望駐留在內存低端，它們使用memory_start和memory_end來傳遞 <BR>該信息。在函數獲得所希望的值后，返回值指明了新的memory_start的值。
<BR>19823：分析傳給內核的各種選項。parse_options函數（19707行，在隨后的“分析內核 <BR>選項”一節中討論）也設置了argv和envp的初值。
<BR>19833：內核運行過程中也可以自行對所進行的工作進行記錄，周期性地對所執行的指令 <BR>進行抽樣，并使用所獲得的結果更新表格。這在定時器中斷過程中通過調用 <BR>x86_do_profile（1896行）來實現，該部分將在第6章中介紹。
<BR>如圖4-1中說明的那樣，這個表格把內核劃分為幾個大小相同的范圍，并簡單跟蹤在一次 <BR>中斷的時間內每個范圍中運行多少條指令。這種記錄當然是非常粗糙的—甚至不是依據函 <BR>數和行號進行劃分的，而只是使用近似的地址—但是這樣代價很低，且快速、短小，而且 <BR>有助于專家判斷最關鍵的問題。每個表格條目所涉及到地址的多少—還有問題發生地點的 <BR>不確定性—可以通過簡單修改prof_shift（26142行）來調節。profile_setup（19076行 <BR>，在本章中后面討論）可以讓你在啟動的時候設置prof_shift的值，這樣比為修改這個數 <BR>字而重新編譯內核要清晰方便得多。
<BR>圖4-1 描述用緩存
<BR>這個if程序塊為記錄表格分配內存，并把所有項都清零。注意到如果prof_shift是0（默 <BR>認值），那么記錄功能就被關掉了，if程序塊不再被執行，也不為表格分配空間。
<BR>19846：內核通過調用sti（UP版本的13104行，注意該主題在第6章中有更詳細的介紹）開 <BR>始接收硬件中斷。首先需要激活定時器中斷，以便后來對calibrate_delay（19654行）的 <BR>調用可以計算機器的BogoMIPS的值（在下一節“BogoMIPS”中介紹）。因為一些設備驅動 <BR>程序需要BogoMIPS的值，所以內核必需在大部分硬件、文件系統等等初始化之前計算出這 <BR>個值來。
<BR>19876：測試該CPU的各種缺陷，比如Pentium F00F缺陷（請參見第8章），記錄檢測到的 <BR>缺陷，以便于內核的其他部分以后可以使用它們工作。（為了節省空間起見，我們省略掉 <BR>了check_bugs函數。）
<BR>19882：調用smp_init（19787行），它又調用了其他的函數來激活SMP系統中的其他CPU： <BR>在x86的平臺上，smp_boot_cpus（4614行）初始化一些內核數據結構，這些數據結構跟蹤 <BR>檢測另外的CPU并簡單的將其改為保持模式；最后smp_commence（4195行）使這些CPU繼續 <BR>執行。
<BR>19883：把init函數作為內核線程終止，這比較復雜；請參閱本章后面有關init的討論。 <BR>
<BR>19885：增加idle進程的need_resched標志，這樣做的原因此時可能還比較模糊。當讀完 <BR>了第5、6、7章以后，就會有個清楚的概念；但是，在下一個定時器中斷結束之前（在第6 <BR>章中討論），system_call（171行，在第5章中討論）函數中會注意到idle進程的 <BR>need_resched標志增加了，并且調用schedule（26686行，第7章）釋放CPU，并將其賦給 <BR>更應該獲取CPU的進程。
<BR>19886：已經完成了內核初始化的工作—或者不管怎樣，已經把需要完成的少量責任傳遞 <BR>給了init，所剩余的工作不過是進入idle循環以消耗空閑的CPU時間片。因此，本行調用 <BR>cpu_idle（2014行）—idle循環。正如你可以從cpu_idle本身可以發現的一樣，該函數從 <BR>不返回。然而，當有實際工作要處理時，該函數就會被搶占。
<BR>注意到cpu_idle只是反復調用idle系統調用（下一章將討論系統調用），它通過sys_idle <BR>（2064行）實現真正的idle循環—2014行對應UP版本，2044行針對SMP版本。它們通過執 <BR>行hlt（對應“halt”）指令把CPU轉入低功耗的“睡眠”狀態。只要沒有實際的工作處理 <BR>，CPU都將轉入這種狀態。
<BR>4.2.1 BogoMIPS
<BR>BogoMIPS的數字由內核計算并在系統初始化的時候打印。它近似給出了每秒鐘CPU可以執 <BR>行一個短延遲循環的次數。在內核中，這個結果主要用于需要等待非常短周期的設備驅動 <BR>程序—例如，等待幾微秒并查看設備的某些信息是否已經可用。
<BR>由于沒有正確理解BogoMIPS的含義，BogoMIPS在各處都被濫用，就仿佛它可以滿足人類最 <BR>原始、最深層次的需求：把所有計算機性能的信息簡化為一個數字。“BogoMIPS”中的“ <BR>Bogo”部分來源于“偽（bogus）”，就正是為了防止這種用法：雖然這個數字比大多數 <BR>基準測試數大，但是它仍然是不準確的、容易引起誤解的、無用的和不真實的，根本不適 <BR>合將它用于機器間差別的對比。但是這個數字仍然非常吸引人，這也正是我們在這里討論 <BR>這個問題的原因。（BogoMIPS 中“MIPS”部分是“millions of instructions per <BR>second（百萬條指令每秒）”的縮寫，這是cpu基準測試中的一個常用單位。）
<BR> calibrate_delay
<BR>19654：calibrate_delay是近似計算BogoMIPS數字的內核函數。
<BR>19622：作為第一次估算，calibrate_delay計算出在每一秒內執行多少次__delay循環（ <BR>6866行），也就是每個定時器滴答（timer tick）—百分之一秒—內延時循環可以執行多 <BR>少次。
<BR>19664：計算一個定時器滴答內可以執行多少次循環需要在滴答開始時就開始計數，或者 <BR>應該盡可能與它接近。全局變量jiffies（16588行）中存儲了從內核開始保持跟蹤時間開 <BR>始到現在已經經過的定時器滴答數；第6章中將介紹它的實現方式。jiffies保持異步更新 <BR>，在一個中斷內—每秒一百次，內核暫時掛起正在處理的內容，更新變量，然后繼續剛才 <BR>的工作。如果不這樣處理，下一行的循環就永遠不可能退出。從而，如果jiffies不聲明 <BR>為volatile—簡單地說，這個值變化的原因對于編譯器是透明的，gcc仍然可能對該循環 <BR>進行優化，并引起該循環進入不能退出的狀態。雖然目前的gcc還沒有如此高的智能，然 <BR>而它的維護者應該完全能夠為它實現這種智能。
<BR>19669：定時器又前移了一個滴答，因此又產生一個新的滴答。下一步是要等待 <BR>loops_per_sec延時循環調用定時器循環，接著檢測是否最少有一個完整的滴答已經完成 <BR>。如果是這樣，就退出首次近似估算循環；如果沒有，就把loops_per_sec的值加倍，然 <BR>后重新啟動這個過程。
<BR>這個循環的正確性依賴于如下的事實：現有的機器在任何地方都不能每秒執行232次延時 <BR>循環（對于64位機來說則遠低于每秒264次)，雖然這只是一個微不足道的問題。
<BR>19677：現在內核已經清楚loops_per_sec循環調用延時循環在這臺機器上要花費超過百分 <BR>之一秒的時間才能完成，因此，內核將重新開始進行估算。為了提高效率，內核使用折半 <BR>查找算法計算loops_per_sec的實際值，我們假定開始的時候，實際值在現在計算結果和 <BR>其一半之間—實際值不可能比現在計算值還大，但是可以（而且可能）稍微小一點。
<BR>19681：和前面使用的方式一樣，calibrate_delay查看這個loops_per_sec已經減小了的 <BR>值是否還是比較大，而需要耗費一個完整的定時器間隔。如果還是相當大，實際值應該小 <BR>于當前計算值或者就是當前值，因此，使用更小的值繼續查詢；如果不夠大，就使用一個 <BR>更大的值繼續查詢。
<BR>19691：內核有一種很好的方法來計算一個定時器滴答中執行延時循環的次數。這個數字 <BR>乘以一秒內滴答的數量就得到了每秒內可以執行的延時循環的次數。這種計算只是一種估 <BR>算，乘法也累積了誤差，因此結果并不能精確到納秒。但是這個數字供內核使用已經足夠 <BR>精確了。
<BR>19693：為了讓用戶感到激動，內核打印出這個數字。注意這里明顯省略了%f的格式限定 <BR>—內核盡量避免浮點數運算。這個計算過程中最有用的常量是500 000；它是用一百萬除 <BR>以2得來，理由是每秒鐘執行一百萬條指令，而每個delay循環的核心是2條指令（decl和 <BR>一條跳轉指令）。
<BR>
<BR> <BR> <BR>-- <BR>※ 來源:·BBS 水木清華站 smth.org·[FROM: 166.111.196.22] <BR><CENTER><H1>BBS水木清華站∶精華區</H1></CENTER></BODY></HTML>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -