【Linux技術】幾個重要的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

• System.map

   /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）文件。