在網路中，不少伺服器使用的是Linux系統。為了進一步提高伺服器的效能，可能需要根據特定的硬體及需求重新編譯Linux核心。編譯Linux核心，需要根據規定的步驟進行，編譯核心過程中涉及到幾個重要的檔案。比如對於RedHat Linux，在/boot目錄下有一些與Linux核心有關的檔案。編譯過RedHat Linux核心的人對其中的System.map 、vmlinuz、initrd-2.4.7-10.img印象可能比較深刻，因為編譯內核過程中涉及到這些檔案的建立等操作。那麼這幾個文件是怎麼產生的？又有什麼作用呢？本文對此做些介紹。
vmlinuz是可引導的(可引導意味著它有能力把作業系統載入至記憶體而使電腦能夠使用並且軟體程序可以運作)、壓縮過的核心。“vm”代表“Virtual Memory”。Linux 支援虛擬記憶體，不像古老的作業系統譬如DOS有640KB記憶體的限制。Linux能夠使用硬碟空間作為虛擬記憶體，因此得名“vm”。vmlinuz是可執行的Linux核心，它位於/boot/vmlinuz，它一般是一個軟鏈接(soft-link)。
vmlinuz的建立有兩種方式。一是編譯核心時通過“make zImage”產生，然後通過：
“cp /usr/src/linux-2.4/arch/i386/linux/boot/zImage /boot/vmlinuz”複製。zImage適用於小核心的情況，它的存在是為了向後的兼容性。二是核心編譯時通過命令"make bzImage"建立，然後通過：“cp /usr/src/linux-2.4/arch/i386/linux/boot/bzImage /boot/vmlinuz”複製。bzImage是壓縮的核心映像檔案，需要注意，bzImage不是用bzip2壓縮的，bzImage中的bz容易引起誤解，bz表示“big zImage”。 bzImage中的b是“big”意思。
zImage（vmlinuz）和bzImage（vmlinuz）都是使用gzip壓縮的。它們不僅是一個壓縮檔案，而且在這兩個檔案的開頭部分內嵌有gzip解壓縮原始碼。所以你不能用gunzip 或 gzip -dc來解壓縮vmlinuz來得到vmlinux。
核心檔案中包含一個微型(小型)的gzip解壓縮程式碼用於解壓縮核心並引導它(可引導意味著它有能力把作業系統載入至記憶體而使電腦能夠使用並且軟體程序可以運作)。兩者的不同之處(zImage)在於，老的zImage解壓縮內核到低端內存（第一個640K），bzImage解壓縮內核到高端內存（1M以上）。如果內核比較小，那麼可以采用zImage 或bzImage之一，兩種方式引導的系統運行時是相同的。大的內核采用bzImage，不能采用zImage。 ( vmlinux是未壓縮的核心，vmlinuz是vmlinux的壓縮核心。 )
vmlinux 是ELF格式檔案，也就是編譯出来的最原始的檔案。
vmlinuz應該是由vmlinux經過arm-linux-objcopy後，並且經過壓縮後的核心檔案
zImage是vmlinuz經過gzip壓縮後的檔案，適用於小核心
bzImage是vmlinuz經過gzip壓縮後的檔案，適用於大核心
zImage是ARM Linux常用的一種壓縮映像檔案，uImage是U-boot專用的映像檔案，它是在zImage檔案前面加上一個長度为0x40的“表頭Header”，說明這個映像檔案的類型、載入位址、建立時間、檔案大小等資訊。換句話說，如果直接從uImage的0x40位置開始執行，zImage和uImage没有任何區別。另外，Linux2.4核心不支援uImage，Linux2.6核心加入了很多對嵌入式系统的支援，但是uImage的建立也需要設定。uImage是u-boot使用bootm命令引導的Linux壓縮核心映像檔案格式， 使用工具mkimage對一般的壓縮核心映像檔案（zImage）加工而得。可以用bootm命令從任意位址解壓啟動核心。由於bootloader一般要占用0X0位址，所以，uImage相比zImage的好處就是可以和bootloader共存。
initrd是“initial ramdisk”的縮寫。initrd一般被用來臨時的引導硬體到實際核心vmlinuz能夠接管並繼續引導的狀態。比如，使用的是scsi硬碟，而核心vmlinuz中並沒有這個scsi硬體的驅動程式，那麼在載入scsi驅動模組之前，核心不能掛載根檔案系統(Root Filesystem)，但scsi驅動模組(*.ko)儲存在根檔案系統的/lib/modules路徑下。為了解決這個問題，可以引導一個能夠讀取實際核心的initrd核心並用initrd修正scsi引導問題。initrd-2.4.7-10.img是用gzip壓縮的檔案，下面來看一看這個檔案的內容。
initrd實現加載一些驅動模組和安裝檔案系統(ext2/ext4 nfs)等。
initrd映象文件是使用mkinitrd創建的。mkinitrd實用程序能夠創建initrd映象文件。這個命令是RedHat專有的。其它Linux發行版或許有相應的命令。這是個很方便的實用程序。具體情況請看幫助：man mkinitrd
內核符號表是怎麼創建的呢? System.map是由“nm vmlinux”產生並且不相關的符號被濾出。對於本文中的例子，編譯內核時，System.map創建在/usr/src/linux-2.4/System.map。像下面這樣：
nm /boot/vmlinux-2.4.7-10 >
System.map
下面幾行來自/usr/src/linux-2.4/Makefile：
nm vmlinux grep -v '(compiled)(.o$$)( [aUw] )(..ng$$)(LASH[RL]DI)' sort >
System.map
然後複制到/boot: cp /usr/src/linux/System.map /boot/System.map-2.4.7-10
在進行程序設計時，會命名一些變量名或函數名之類的符號。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為了執行名稱-地址解析，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）檔案。
（出處：http://southmaster.com）
留言列表
{{ article.title }}