第2章   代 碼 初 識本章首先從較高層次介紹Linux內核源程序的概況，這些都是大家關心的一些基本特點。隨后將簡要介紹一些實際代碼。最后介紹如何編譯內核。2.1   Linux內核源程序的部分特點在過去的一段時期，Linux內核同時使用C語言和匯編語言來實現。這兩種語言需要一定的平衡：C語言編寫的代碼移植性較好、易于維護，而匯編語言編寫的程序則速度較快。一般只有在速度是關鍵因素或者一些因平臺相關特性而產生的特殊要求（例如直接和內存管理硬件進行通訊）時才使用匯編語言。正如實際中所做的，即使內核并未使用C++的對象特性，部分內核也可以在g++（GNU的C++編譯器）下進行編譯。同其他面向對象的編程語言相比較，相對而言C++的開銷是較低的，但是對于內核開發人員來說，這已經是太多了。內核開發人員不斷發展編程風格，形成了Linux代碼獨有的特色。本節將討論其中的一些問題。2.1.1   gcc特性的使用Linux內核被設計為必須使用GNU的C編譯器gcc來編譯，而不是任何一種C編譯器都可以使用。內核代碼有時要使用gcc特性，本書將陸續介紹其中的一部分。一些gcc特有代碼只是簡單地使用gcc語言擴展，例如允許在C（不只是C++）中使用inline關鍵字指示內聯函數。也就是說，代碼中被調用的函數在每次函數調用時都會被擴充，因而就可以節約實際函數調用的開銷。一般情況下，代碼的編寫方式比較復雜。因為對于某些類型的輸入，gcc能夠產生比其他輸入效率更高的執行代碼。從理論上講，編譯器可以優化具有相同功能的兩種對等的方法，并且得到相同的結果。因此，代碼的編寫方式是無關緊要的。但在實際上，用某種方法編寫所產生的代碼要比用另外一些方法編寫所產生的代碼執行速度快許多。內核開發人員知道怎樣才能產生更高效的執行代碼，這不斷地在他們編寫的代碼中反映出來。例如，考慮內核中經常使用的goto語句—為了提高速度，內核中經常大量使用這種一般要避免使用的語句。在本書中所包含的不到40 000行代碼中，一共有500多條goto語句，大約是每80行一個。除匯編文件外，精確的統計數字是接近每72行一個goto語句。公平地說，這是選擇偏向的結果：比例如此高的原因之一是本書中涉及的是內核源程序的核心，在這里速度比其他因素都需要優先考慮。整個內核的比例大概是每260行一個goto語句。然而，這仍然是我不再使用Basic進行編程以來見過的使用goto頻率最高的地方。代碼必需受特定編譯器限制的特性不僅與普通應用程序的開發有很大不同，而且也不同于大多數內核的開發。大多數的開發人員使用C語言編寫代碼來保持較高的可移植性，即使在編寫操作系統時也是如此。這樣做的優點是顯而易見的，最為重要的一點是一旦出現更好的編譯器，程序員們可以隨時進行更換。內核對于gcc特性的完全依賴使得內核向新的編譯器上移植更加困難。最近Linus對這一問題在有關內核的郵件列表上表明了自己的觀點：“記住，編譯器只是一個工具。”這是對依賴于gcc特性的一個很好的基本思想的表述：編譯器只是為了完成工作。如果通過遵守標準還不能達到工作要求，那么就不是工作要求有問題，而是對于標準的依賴有問題。在大多數情況下，這種觀點是不能被人所接受的。通常情況下，為了保證和程序語言標準的一致，開發人員可能需要犧牲某些特性、速度或者其他相關因素。其他的選擇可能會為后期開發造成很大的麻煩。但是，在這種特定的情況下，Linus是正確的。Linux內核是一個特例，因為其執行速度要比向其他編譯器的可移植性遠為重要。如果設計目標是編寫一個可移植性好而不要求快速運行的內核，或者是編寫一個任何人都可以使用自己喜歡的編譯器進行編譯的內核，那么結論就可能會有所不同了；而這些恰好不是Linux的設計目標。實際上，gcc幾乎可以為所有能夠運行Linux的CPU生成代碼，因此，對于gcc的依賴并不是可移植性的嚴重障礙。在第3章中我們將對內核設計目標進行詳細說明。2.1.2   內核代碼習慣用語內核代碼中使用了一些顯著的習慣用語，本節將介紹常用的幾個。當通讀源代碼時，真正重要的問題并不在這些習慣用語本身，而是這種類型的習慣用語的確存在，而且是不斷被使用和發展的。如果你需要編寫內核代碼，你應該注意到內核中所使用的習慣用語，并把這些習慣用語應用到你的代碼中。當通讀本書（或者代碼）時，看看你還能找到多少習慣用語。為了討論這些習慣用語，我們首先需要對它們進行命名。為了便于討論，筆者創造了這些名字。而在實際中，大家不一定非要參考這些用語，它們只是對內核工作方式的描述而已。一個普通的習慣用語，筆者稱之為“資源獲取”（resource acquisition idiom）。在這個用語中，一個函數必須實現一系列資源的獲取，包括內存、鎖等等（這些資源的類型未必相同）。只有成功地獲取當前所需要的資源之后，才能處理后面的資源請求。最后，該函數還必須釋放所有已經獲取的資源，而不必考慮沒有獲取的資源。我采用“錯誤變量”這一用語（error variable idiom）來輔助說明資源獲取用語，它使用一個臨時變量來記錄函數的期望返回值。當然，相當多的函數都能實現這個功能。但是錯誤變量的不同點在于它通常是用來處理由于速度的因素而變得非常復雜的流程控制中的問題。錯誤變量有兩個典型的值，0（表示成功）和負數（表示有錯）。這兩個用語結合使用，我們就可以十分自然地得到符合模式的代碼如下：（注意變量err是使用錯誤變量的一個明確實例，同樣，諸如out之類的標號則指明了資源獲取用語的使用。）如果執行到標號out2，則都已經獲取了r1和r2資源，而且也都需要進行釋放。如果執行到標號out1（不管是順序執行還是使用goto語句進行跳轉到），則r2資源是無效的（也可能剛被釋放），但是r1資源卻是有效的，而且必需在此將其釋放。同理，如果標號out能被執行，則r1和r2資源都無效，err所返回的是錯誤或成功標志。在這個簡單的例子中，對err的一些賦值是沒有必要的。在實踐中，實際代碼必須遵守這種模式。這樣做的原因主要在于同一行中可能包含有多種測試，而這些測試應該返回相同的錯誤代碼，因此對錯誤變量統一賦值要比多次賦值更為簡單。雖然在這個例子中對于這種屬性的必要性并不非常迫切，但是我還是傾向于保留這種特點。有關的實際應用可以參考sys_shmctl（第21654行），在第9章中還將詳細介紹這個例子。2.1.3   減少#if和#ifdef的使用現在的Linux內核已經移植到不同的平臺上，但是我們還必須解決移植過程中所出現的問題。大部分支持各種不同平臺的代碼由于包含許多預處理代碼而已經變得非常不規范，例如：這個例子試圖實現操作系統的可移植性，雖然Linux關注的焦點很明顯是實現代碼在各種CPU上的可移植性，但是二者的基本原理是一致的。對于這類問題來說，預處理器是一種錯誤的解決方式。這些雜亂的問題使得代碼晦澀難懂。更為糟糕的是，增加對新平臺的支持有可能要求重新遍歷這些雜亂分布的低質量代碼段（實際上你很難能找到這類代碼段的全部）。與現有方式不同的是，Linux一般通過簡單函數（或者是宏）調用來抽象出不同平臺間的差異。內核的移植可以通過實現適合于相應平臺的函數（或宏）來實現。這樣不僅使代碼的主體簡單易懂，而且在移植的過程中還可以比較容易地自動檢測出你沒有注意到的內容：如引用未聲明函數時會出現鏈接錯誤。有時用預處理器來支持不同的體系結構，但這種方式并不常用，而相對于代碼風格的變化就更是微不足道了。順便說一下，我們可以注意到這種解決方法和使用用戶對象（或者C語言中充滿函數指針的struct結構）來代替離散的switch語句處理不同類型的方法十分相似。在某些層次上，這些問題和解決方法是統一的。可移植性的問題并不僅限于平臺和CPU的移植，編譯器也是一個重要的問題。此處為了簡化，假設Linux只使用gcc來編譯。由于Linux只使用同一個編譯器，所以就沒有必要使用#if塊（或者#ifdef塊）來選擇不同的編譯器。內核代碼主要使用#ifdef來區分需要編譯或不需要編譯的部分，從而對不同的結構提供支持。例如，代碼經常測試SMP宏是否定義過，從而決定是否支持SMP機。2.2   代碼樣例了解Linux代碼風格最好的方法就是實際研究一下它的部分代碼。即使你不完全理解本節所討論代碼的細節也無關緊要，畢竟本節的主要目的不是理解代碼，一些讀者可以只對本節進行瀏覽。本節的主要目的是讓讀者對Linux代碼進行初步了解，為今后的工作提供必要基礎。該討論將涉及部分廣泛使用的內核代碼。2.2.1   printkprintk（25836行）是內核內部消息日志記錄函數。在出現諸如內核檢測到其數據結構出現不一致的事件時，內核會使用printk把相關信息打印到系統控制臺上。對于printk的調用一般分為如下幾類：