【核心】幾個重要的linux核心檔案【轉】

Preface

   當使用者編譯一個linux核心代碼後，會産生幾個檔案：vmlinz、initrd.img, 以及System.map，如果配置過grub引導管理器程式，會在/boot目錄下看到這幾個檔案。

vmlinuz

   vmlinuz是可引導的、壓縮的核心檔案。

   該檔案包含了一個最小功能的核心，在PC上通常是先執行vmlinuz，之後加載initrd.img檔案，最後加載根分區。

   實際上initrd.img是可選的，從檔案大小來看，initrd.img比vmlinuz檔案大得多，initrd.img也包含了較多的功能，如果不需要額外的功能，例如在一些功能需求較小的嵌入式系統上，可以僅使用vmlinuz檔案存放核心，而省去initrd.img檔案。

   “vm”代表“Virtual Memory”。Linux 支援虛拟記憶體，不像老的作業系統比如DOS有640KB記憶體的限制。Linux能夠使用硬碟空間作為虛拟記憶體，是以得名“vm”。vmlinuz是可執行的Linux核心，它位于/boot/vmlinuz，它一般是一個軟連結。

vmlinuz的建立有兩種方式。

   一是編譯核心時通過“make zImage”建立。zImage适用于小核心的情況，它的存在是為了向後的相容性。

   二是編譯核心時通過“make bzImage”建立，然後通過。bzImage是壓縮的核心映像，需要注意，bzImage不是用bzip2壓縮的，bzImage中的bz容易引起誤解，bz表示“big zImage”。 bzImage中的b是“big”意思。

   zImage（vmlinuz）和bzImage（vmlinuz）都是用gzip壓縮的。它們不僅是一個壓縮檔案，而且在這兩個檔案的開頭部分内嵌有gzip解壓縮代碼。是以你不能用gunzip 或 gzip –dc解包vmlinuz。

   核心檔案中包含一個微型的gzip用于解壓縮核心并引導它。兩者的不同之處在于，zImage解壓縮核心到低端記憶體（第一個640K），bzImage解壓縮核心到高端記憶體（1M以上）。如果核心比較小，那麼可以采用zImage 或bzImage之一，兩種方式引導的系統運作時是相同的。大的核心采用bzImage，不能采用zImage。

   核心編譯之後還有一個vmlinux檔案，vmlinux是未壓縮的核心，vmlinuz是vmlinux的壓縮檔案。

initrd檔案

   initrd是“initial ramdisk”的簡寫。就是由Bootloader初始化的記憶體盤。

   在linux核心啟動之前，Bootloader會把存儲媒體（例如閃存）中的initrd檔案加載到記憶體，核心啟動時會在通路到真正的根檔案系統前通路記憶體中的initrd檔案系統。

   如果Bootloader配置了initrd，核心啟動被分成兩個階段：

第一階段先加載initrd檔案系統中的驅動程式子產品；

第二階段才會執行真正的根檔案系統中的/sbin/init程序。

   第一階段啟動的目的是為第二階段啟動掃清障礙，linux根檔案系統支援多種存儲媒體（如IDE、SCSI、USB等），如果把這些裝置的驅動都編譯進核心，核心會十分龐大，使用initrd存放裝置驅動很好地解決了這一問題。

   在啟動順序上，initrd會在vmlinuz代碼執行完之後加載，使用initrd的機制可以很好地解決不同硬體環境的情況，是linux發行版，以USB裝置啟動的必備。在嵌入式系統上，在硬體相對固定的情況下，initrd作用不像PC上那麼大，但是對于調試裝置驅動起到了簡化調試步驟的作用。

   initrd一般被用來臨時的引導硬體到實際核心vmlinuz能夠接管并繼續引導的狀态。比如，使用的是scsi硬碟，而核心vmlinuz中并沒有這個scsi硬體的驅動，那麼在裝入scsi子產品之前，核心不能加載根檔案系統，但scsi子產品存儲在根檔案系統的/lib/modules下。為了解決這個問題，可以引導一個能夠讀實際核心的initrd核心并用initrd修正scsi引導問題。

   initrd實作加載一些子產品和安裝檔案系統等。

   initrd映象檔案是使用mkinitrd建立的。mkinitrd實用程式能夠建立initrd映象檔案。這個指令是RedHat專有的。其它Linux發行版或許有相應的指令。這是個很友善的實用程式。具體情況請看幫助：man mkinitrd

System.map

   System.map是一個特定核心的核心符号表。它是你目前運作的核心的System.map的連結。

   System.map是由“nm vmlinux”産生并且不相關的符号被濾出。

   在進行程式設計時，會命名一些變量名或函數名之類的符号。Linux核心是一個很複雜的代碼塊，有許許多多的全局符号。

   Linux核心不使用符号名，而是通過變量或函數的位址來識别變量或函數名。比如不是使用size_t BytesRead這樣的符号，而是像c0343f20這樣引用這個變量。

   對于使用計算機的人來說，更喜歡使用那些像size_t BytesRead這樣的名字，而不喜歡像c0343f20這樣的名字。核心主要是用c寫的，是以編譯器/連接配接器允許我們編碼時使用符号名，當核心運作時使用位址(使用符号表查詢一個符号對應的位址，或者通過記憶體位址得到一個符号名稱)。

   然而，在有的情況下，我們需要知道符号的位址，或者需要知道位址對應的符号。這由符号表來完成，符号表是所有符号連同它們的位址的清單。

   Linux 符号表使用到2個檔案：

/proc/ksyms

   /proc/ksyms是一個“proc file”，在核心引導時建立。實際上，它并不真正的是一個檔案，它隻不過是核心資料的表示，卻給人們是一個磁盤檔案的假象，這從它的檔案大小是0可以看出來。

   System.map是存在于你的檔案系統上的實際檔案。當你編譯一個新核心時，各個符号名的位址要發生變化，你的老的System.map具有的是錯誤的符号資訊。每次核心編譯時産生一個新的System.map，你應當用新的System.map來取代老的System.map。

   雖然核心本身并不真正使用System.map，但其它程式比如klogd， lsof和ps等軟體需要一個正确的System.map。如果你使用錯誤的或沒有System.map，klogd的輸出将是不可靠的，這對于排除程式故障會帶來困難。

   沒有System.map，你可能會面臨一些令人煩惱的提示資訊。

   另外少數驅動需要System.map來解析符号，沒有為你目前運作的特定核心建立的System.map它們就不能正常工作。

    Linux的核心日志守護程序klogd為了執行名稱-位址解析，需要使用System.map。System.map應當放在使用它的軟體能夠找到它的地方。

   執行：man klogd可知，如果沒有将System.map作為一個變量的位置給klogd，那麼它将按照下面的順序，在三個地方查找System.map：

/boot/System.map

/System.map

/usr/src/linux/System.map

   System.map也有版本資訊，klogd能夠智能地查找正确的映象（map）檔案。

本文轉自張昺華-sky部落格園部落格，原文連結：http://www.cnblogs.com/sky-heaven/p/5066634.html，如需轉載請自行聯系原作者