?? 00000003.htm
字號:
<HTML><HEAD> <TITLE>BBS水木清華站∶精華區(qū)</TITLE></HEAD><BODY><CENTER><H1>BBS水木清華站∶精華區(qū)</H1></CENTER>發(fā)信人: axp33a (無聊中...), 信區(qū): Linux <BR>標(biāo) 題: Linux內(nèi)核源代碼分析2-1 <BR>發(fā)信站: BBS 水木清華站 (Thu Aug 3 11:18:30 2000) WWW-POST <BR> <BR>第2章 代 碼 初 識
<BR>本章首先從較高層次介紹Linux內(nèi)核源程序的概況，這些都是大家關(guān)心的一些基本特點(diǎn)。 <BR>隨后將簡要介紹一些實(shí)際代碼。最后介紹如何編譯內(nèi)核。
<BR>2.1 Linux內(nèi)核源程序的部分特點(diǎn)
<BR>在過去的一段時(shí)期，Linux內(nèi)核同時(shí)使用C語言和匯編語言來實(shí)現(xiàn)。這兩種語言需要一定的 <BR>平衡：C語言編寫的代碼移植性較好、易于維護(hù)，而匯編語言編寫的程序則速度較快。一 <BR>般只有在速度是關(guān)鍵因素或者一些因平臺相關(guān)特性而產(chǎn)生的特殊要求（例如直接和內(nèi)存管 <BR>理硬件進(jìn)行通訊）時(shí)才使用匯編語言。
<BR>正如實(shí)際中所做的，即使內(nèi)核并未使用C++的對象特性，部分內(nèi)核也可以在g++（GNU的C++ <BR>編譯器）下進(jìn)行編譯。同其他面向?qū)ο蟮木幊陶Z言相比較，相對而言C++的開銷是較低的 <BR>，但是對于內(nèi)核開發(fā)人員來說，這已經(jīng)是太多了。
<BR>內(nèi)核開發(fā)人員不斷發(fā)展編程風(fēng)格，形成了Linux代碼獨(dú)有的特色。本節(jié)將討論其中的一些 <BR>問題。
<BR>2.1.1 gcc特性的使用
<BR>Linux內(nèi)核被設(shè)計(jì)為必須使用GNU的C編譯器gcc來編譯，而不是任何一種C編譯器都可以使 <BR>用。內(nèi)核代碼有時(shí)要使用gcc特性，本書將陸續(xù)介紹其中的一部分。
<BR>一些gcc特有代碼只是簡單地使用gcc語言擴(kuò)展，例如允許在C（不只是C++）中使用inline <BR>關(guān)鍵字指示內(nèi)聯(lián)函數(shù)。也就是說，代碼中被調(diào)用的函數(shù)在每次函數(shù)調(diào)用時(shí)都會被擴(kuò)充，因 <BR>而就可以節(jié)約實(shí)際函數(shù)調(diào)用的開銷。
<BR>一般情況下，代碼的編寫方式比較復(fù)雜。因?yàn)閷τ谀承╊愋偷妮斎耄琯cc能夠產(chǎn)生比其他 <BR>輸入效率更高的執(zhí)行代碼。從理論上講，編譯器可以優(yōu)化具有相同功能的兩種對等的方法 <BR>，并且得到相同的結(jié)果。因此，代碼的編寫方式是無關(guān)緊要的。但在實(shí)際上，用某種方法 <BR>編寫所產(chǎn)生的代碼要比用另外一些方法編寫所產(chǎn)生的代碼執(zhí)行速度快許多。內(nèi)核開發(fā)人員 <BR>知道怎樣才能產(chǎn)生更高效的執(zhí)行代碼，這不斷地在他們編寫的代碼中反映出來。
<BR>例如，考慮內(nèi)核中經(jīng)常使用的goto語句—為了提高速度，內(nèi)核中經(jīng)常大量使用這種一般要 <BR>避免使用的語句。在本書中所包含的不到40 000行代碼中，一共有500多條goto語句，大 <BR>約是每80行一個(gè)。除匯編文件外，精確的統(tǒng)計(jì)數(shù)字是接近每72行一個(gè)goto語句。公平地說 <BR>，這是選擇偏向的結(jié)果：比例如此高的原因之一是本書中涉及的是內(nèi)核源程序的核心，在 <BR>這里速度比其他因素都需要優(yōu)先考慮。整個(gè)內(nèi)核的比例大概是每260行一個(gè)goto語句。然 <BR>而，這仍然是我不再使用Basic進(jìn)行編程以來見過的使用goto頻率最高的地方。
<BR>代碼必需受特定編譯器限制的特性不僅與普通應(yīng)用程序的開發(fā)有很大不同，而且也不同于 <BR>大多數(shù)內(nèi)核的開發(fā)。大多數(shù)的開發(fā)人員使用C語言編寫代碼來保持較高的可移植性，即使 <BR>在編寫操作系統(tǒng)時(shí)也是如此。這樣做的優(yōu)點(diǎn)是顯而易見的，最為重要的一點(diǎn)是一旦出現(xiàn)更 <BR>好的編譯器，程序員們可以隨時(shí)進(jìn)行更換。
<BR>內(nèi)核對于gcc特性的完全依賴使得內(nèi)核向新的編譯器上移植更加困難。最近Linus對這一問 <BR>題在有關(guān)內(nèi)核的郵件列表上表明了自己的觀點(diǎn)：“記住，編譯器只是一個(gè)工具。”這是對 <BR>依賴于gcc特性的一個(gè)很好的基本思想的表述：編譯器只是為了完成工作。如果通過遵守 <BR>標(biāo)準(zhǔn)還不能達(dá)到工作要求，那么就不是工作要求有問題，而是對于標(biāo)準(zhǔn)的依賴有問題。
<BR>在大多數(shù)情況下，這種觀點(diǎn)是不能被人所接受的。通常情況下，為了保證和程序語言標(biāo)準(zhǔn) <BR>的一致，開發(fā)人員可能需要犧牲某些特性、速度或者其他相關(guān)因素。其他的選擇可能會為 <BR>后期開發(fā)造成很大的麻煩。
<BR>但是，在這種特定的情況下，Linus是正確的。Linux內(nèi)核是一個(gè)特例，因?yàn)槠鋱?zhí)行速度要 <BR>比向其他編譯器的可移植性遠(yuǎn)為重要。如果設(shè)計(jì)目標(biāo)是編寫一個(gè)可移植性好而不要求快速 <BR>運(yùn)行的內(nèi)核，或者是編寫一個(gè)任何人都可以使用自己喜歡的編譯器進(jìn)行編譯的內(nèi)核，那么 <BR>結(jié)論就可能會有所不同了；而這些恰好不是Linux的設(shè)計(jì)目標(biāo)。實(shí)際上，gcc幾乎可以為所 <BR>有能夠運(yùn)行Linux的CPU生成代碼，因此，對于gcc的依賴并不是可移植性的嚴(yán)重障礙。
<BR>在第3章中我們將對內(nèi)核設(shè)計(jì)目標(biāo)進(jìn)行詳細(xì)說明。
<BR>2.1.2 內(nèi)核代碼習(xí)慣用語
<BR>內(nèi)核代碼中使用了一些顯著的習(xí)慣用語，本節(jié)將介紹常用的幾個(gè)。當(dāng)通讀源代碼時(shí)，真正 <BR>重要的問題并不在這些習(xí)慣用語本身，而是這種類型的習(xí)慣用語的確存在，而且是不斷被 <BR>使用和發(fā)展的。如果你需要編寫內(nèi)核代碼，你應(yīng)該注意到內(nèi)核中所使用的習(xí)慣用語，并把 <BR>這些習(xí)慣用語應(yīng)用到你的代碼中。當(dāng)通讀本書（或者代碼）時(shí)，看看你還能找到多少習(xí)慣 <BR>用語。
<BR>為了討論這些習(xí)慣用語，我們首先需要對它們進(jìn)行命名。為了便于討論，筆者創(chuàng)造了這些 <BR>名字。而在實(shí)際中，大家不一定非要參考這些用語，它們只是對內(nèi)核工作方式的描述而已 <BR>。
<BR>一個(gè)普通的習(xí)慣用語，筆者稱之為“資源獲取”（resource acquisition idiom）。在這 <BR>個(gè)用語中，一個(gè)函數(shù)必須實(shí)現(xiàn)一系列資源的獲取，包括內(nèi)存、鎖等等（這些資源的類型未 <BR>必相同）。只有成功地獲取當(dāng)前所需要的資源之后，才能處理后面的資源請求。最后，該 <BR>函數(shù)還必須釋放所有已經(jīng)獲取的資源，而不必考慮沒有獲取的資源。
<BR>我采用“錯(cuò)誤變量”這一用語（error variable idiom）來輔助說明資源獲取用語，它使 <BR>用一個(gè)臨時(shí)變量來記錄函數(shù)的期望返回值。當(dāng)然，相當(dāng)多的函數(shù)都能實(shí)現(xiàn)這個(gè)功能。但是 <BR>錯(cuò)誤變量的不同點(diǎn)在于它通常是用來處理由于速度的因素而變得非常復(fù)雜的流程控制中的 <BR>問題。錯(cuò)誤變量有兩個(gè)典型的值，0（表示成功）和負(fù)數(shù)（表示有錯(cuò)）。
<BR>這兩個(gè)用語結(jié)合使用，我們就可以十分自然地得到符合模式的代碼如下：
<BR>（注意變量err是使用錯(cuò)誤變量的一個(gè)明確實(shí)例，同樣，諸如out之類的標(biāo)號則指明了資源 <BR>獲取用語的使用。）
<BR>如果執(zhí)行到標(biāo)號out2，則都已經(jīng)獲取了r1和r2資源，而且也都需要進(jìn)行釋放。如果執(zhí)行到 <BR>標(biāo)號out1（不管是順序執(zhí)行還是使用goto語句進(jìn)行跳轉(zhuǎn)到），則r2資源是無效的（也可能 <BR>剛被釋放），但是r1資源卻是有效的，而且必需在此將其釋放。同理，如果標(biāo)號out能被 <BR>執(zhí)行，則r1和r2資源都無效，err所返回的是錯(cuò)誤或成功標(biāo)志。
<BR>在這個(gè)簡單的例子中，對err的一些賦值是沒有必要的。在實(shí)踐中，實(shí)際代碼必須遵守這 <BR>種模式。這樣做的原因主要在于同一行中可能包含有多種測試，而這些測試應(yīng)該返回相同 <BR>的錯(cuò)誤代碼，因此對錯(cuò)誤變量統(tǒng)一賦值要比多次賦值更為簡單。雖然在這個(gè)例子中對于這 <BR>種屬性的必要性并不非常迫切，但是我還是傾向于保留這種特點(diǎn)。有關(guān)的實(shí)際應(yīng)用可以參 <BR>考sys_shmctl（第21654行），在第9章中還將詳細(xì)介紹這個(gè)例子。
<BR>2.1.3 減少#if和#ifdef的使用
<BR>現(xiàn)在的Linux內(nèi)核已經(jīng)移植到不同的平臺上，但是我們還必須解決移植過程中所出現(xiàn)的問 <BR>題。大部分支持各種不同平臺的代碼由于包含許多預(yù)處理代碼而已經(jīng)變得非常不規(guī)范，例 <BR>如：
<BR>這個(gè)例子試圖實(shí)現(xiàn)操作系統(tǒng)的可移植性，雖然Linux關(guān)注的焦點(diǎn)很明顯是實(shí)現(xiàn)代碼在各種 <BR>CPU上的可移植性，但是二者的基本原理是一致的。對于這類問題來說，預(yù)處理器是一種 <BR>錯(cuò)誤的解決方式。這些雜亂的問題使得代碼晦澀難懂。更為糟糕的是，增加對新平臺的支 <BR>持有可能要求重新遍歷這些雜亂分布的低質(zhì)量代碼段（實(shí)際上你很難能找到這類代碼段的 <BR>全部）。
<BR>與現(xiàn)有方式不同的是，Linux一般通過簡單函數(shù)（或者是宏）調(diào)用來抽象出不同平臺間的 <BR>差異。內(nèi)核的移植可以通過實(shí)現(xiàn)適合于相應(yīng)平臺的函數(shù)（或宏）來實(shí)現(xiàn)。這樣不僅使代碼 <BR>的主體簡單易懂，而且在移植的過程中還可以比較容易地自動(dòng)檢測出你沒有注意到的內(nèi)容 <BR>：如引用未聲明函數(shù)時(shí)會出現(xiàn)鏈接錯(cuò)誤。有時(shí)用預(yù)處理器來支持不同的體系結(jié)構(gòu)，但這種 <BR>方式并不常用，而相對于代碼風(fēng)格的變化就更是微不足道了。
<BR>順便說一下，我們可以注意到這種解決方法和使用用戶對象（或者C語言中充滿函數(shù)指針 <BR>的struct結(jié)構(gòu)）來代替離散的switch語句處理不同類型的方法十分相似。在某些層次上， <BR>這些問題和解決方法是統(tǒng)一的。
<BR>可移植性的問題并不僅限于平臺和CPU的移植，編譯器也是一個(gè)重要的問題。此處為了簡 <BR>化，假設(shè)Linux只使用gcc來編譯。由于Linux只使用同一個(gè)編譯器，所以就沒有必要使用 <BR>#if塊（或者#ifdef塊）來選擇不同的編譯器。
<BR>內(nèi)核代碼主要使用#ifdef來區(qū)分需要編譯或不需要編譯的部分，從而對不同的結(jié)構(gòu)提供支 <BR>持。例如，代碼經(jīng)常測試SMP宏是否定義過，從而決定是否支持SMP機(jī)。
<BR>
<BR> <BR> <BR>-- <BR>※ 來源:·BBS 水木清華站 smth.org·[FROM: 166.111.196.22] <BR><CENTER><H1>BBS水木清華站∶精華區(qū)</H1></CENTER></BODY></HTML>?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -