本文主要帶大家深入研究 Linux 系統(tǒng)編程。系統(tǒng)編程的任務(wù)，可以定義為使用系統(tǒng)提供的功能解決我們面對的實際問題，而系統(tǒng)調(diào)用，則是系統(tǒng)開放給應(yīng)用執(zhí)行特定功能的接口。本文首先從 Linux 系統(tǒng)調(diào)用講起，主要包括以下內(nèi)容：

• 系統(tǒng)調(diào)用概述
• 系統(tǒng)調(diào)用的兩種調(diào)用方式
• 系統(tǒng)調(diào)用的兩種執(zhí)行過程
• 系統(tǒng)調(diào)用的標(biāo)準(zhǔn)使用方法

另外，還會擴展兩個知識點：

• 與早期 Linux 相比，2.6 以后版本的內(nèi)核，是如何實現(xiàn)更高效的系統(tǒng)調(diào)用的?
• 全局 errno 是如何解決多線程沖突問題的?

[[259559]]

1.1 系統(tǒng)調(diào)用概述

系統(tǒng)調(diào)用是操作系統(tǒng)內(nèi)核提供給應(yīng)用程序的基礎(chǔ)接口，需要運行在操作系統(tǒng)的核心模式下，以確保有權(quán)限執(zhí)行某些 CPU 特權(quán)指令。

Linux 系統(tǒng)提供了功能非常豐富的系統(tǒng)調(diào)用，涵蓋了文件操作、進程控制、內(nèi)存管理、網(wǎng)絡(luò)管理、套接字操作、用戶管理、進程間通信等各個方面。

執(zhí)行如下命令，可列出系統(tǒng)中所有的系統(tǒng)調(diào)用名稱。

man syscalls 

Linux 自帶的 man 手冊對每個系統(tǒng)調(diào)用都進行了非常詳細的說明，包括函數(shù)功能、傳入的參數(shù)、返回值，以及可能產(chǎn)生的錯誤、使用注意事項，等等，其完善程度絲毫不亞于微軟的 MSDN。雖然是英文版，但讀起來比較通俗易懂，每位 Linux 系統(tǒng)開發(fā)者都應(yīng)該習(xí)慣于查看這些文檔。

另外，IBM 文檔庫里有一份質(zhì)量非常高的《中文版系統(tǒng)調(diào)用列表》，閱讀它會更輕松。

1.2 系統(tǒng)調(diào)用的兩種調(diào)用方式

我們先看一種方式。

系統(tǒng)調(diào)用由指派的編號來標(biāo)識，通過 syscall 函數(shù)以編號為參數(shù)可直接被調(diào)用。

syscall 函數(shù)原型為：

int syscall(int number, ...); 

完整的系統(tǒng)調(diào)用編號都定義在 sys/syscall.h 的文件中。感興趣的讀者可以自行查看。

顯然，記憶如此多的編號，對開發(fā)者很不友好。

于是，開發(fā)者多會選擇第二種方式，即利用 glibc 提供的包裝函數(shù)將這些系統(tǒng)調(diào)用包裝成名字自解釋的函數(shù)。

這個過程，包裝函數(shù)并沒有做太多額外工作，主要是檢查參數(shù)，將它們拷貝到合適的寄存器中，接著調(diào)用指定標(biāo)號的系統(tǒng)調(diào)用，之后再根據(jù)結(jié)果設(shè)置 errno，供應(yīng)用程序檢查執(zhí)行結(jié)果，以及其他相關(guān)工作。

兩種調(diào)用方式，在功能上可以認(rèn)為是完全等價的，但在易讀、易用性上，glibc 包裝函數(shù)則更有優(yōu)勢。在之后的課程中，我提到某系統(tǒng)調(diào)用，若無特殊說明，指的便是 glibc 包裝函數(shù)。

當(dāng)然，如果包裝函數(shù)無法滿足某些特殊應(yīng)用場景需求，還可以使用 syscall 函數(shù)直接執(zhí)行系統(tǒng)調(diào)用。不過這種情況非常少見，到目前為止，我還沒有遇到過。

1.3 系統(tǒng)調(diào)用的兩種執(zhí)行過程

1.3.1 基于中斷方式

系統(tǒng)調(diào)用的實現(xiàn)代碼是內(nèi)核代碼的一部分。執(zhí)行系統(tǒng)調(diào)用代碼，首先需要將系統(tǒng)從用戶模式切換到核心模式。

早期的系統(tǒng)調(diào)用通過軟中斷實現(xiàn)模式的切換，而中斷號屬于系統(tǒng)稀缺資源，不可能為每個系統(tǒng)調(diào)用都分配一個中斷號。

在 Linux 的實現(xiàn)中，所有的系統(tǒng)調(diào)用共用 128 號中斷(也就是大名鼎鼎的 int 0x80 )，其對應(yīng)的中斷處理程序是 system_call，所有的系統(tǒng)調(diào)用都會轉(zhuǎn)到這個中斷處理程序中。

接著，system_call 會根據(jù) EAX 傳入的系統(tǒng)調(diào)用標(biāo)號跳轉(zhuǎn)并執(zhí)行相應(yīng)的系統(tǒng)調(diào)用程序。如果需要更多的參數(shù)，會依次用 EBX、ECX、EDX、EDI 進行傳遞。函數(shù)執(zhí)行完成之后，會把結(jié)果放到 EAX 中返回給應(yīng)用程序。

由此可知，一次系統(tǒng)調(diào)用便會觸發(fā)一次完整的中斷處理過程。在每次中斷處理過程中，CPU 都會從系統(tǒng)啟動時初始化好的中斷描述表中，取出該中斷對應(yīng)的門描述符，并判斷門描述符的種類。

在確認(rèn)門描述符的級別(DPL)不比中斷指令調(diào)用者的級別(CPL)低之后，再根據(jù)描述符的內(nèi)容，將中斷處理程序中可能用到的寄存器進行壓棧保存。然后，執(zhí)行權(quán)限提升，設(shè)置 CS 和 EIP 寄存器，以使 CPU 跳轉(zhuǎn)到指定的系統(tǒng)調(diào)用的代碼地址，并執(zhí)行目標(biāo)系統(tǒng)調(diào)用。

1.3.2 基于 SYSENTER 指令

再仔細審視基于中斷方式的系統(tǒng)調(diào)用的執(zhí)行過程，不難發(fā)現(xiàn)，前面很多處理過程都是固定的，其實很沒必要，如門描述符級別檢查、查找中斷處理程序入口，等等。

為了省去這些多余的檢查，Intel 在 Pentium II CPU 中加入了新的 SYSENTER 指令，專門用來執(zhí)行系統(tǒng)調(diào)用。

該指令會跳過前面檢查步驟，直接將 CPU 切換到特權(quán)模式，繼而執(zhí)行系統(tǒng)調(diào)用，同時還增加了幾個專用寄存器輔助完成參數(shù)傳遞和上下文保存工作。另外，還相應(yīng)地增加了 SYSEXIT 指令，用來返回執(zhí)行結(jié)果，并切回用戶模式。

在 Linux 實現(xiàn)了 SYSENTER 方式的系統(tǒng)調(diào)用之后，就有人用 Pentium III 的機器對比測試了兩種系統(tǒng)調(diào)用的效率。測試結(jié)果顯示，與中斷方式相比，SYSENTER 在用戶模式下因省掉了級別檢查類的操作，花費的時間大幅減少了 45% 左右;在核心模式下，因少了一個寄存器壓棧保存動作，所花費的時間也減少了 2% 左右。

目前，基于中斷方式的系統(tǒng)調(diào)用仍然保留著，Linux 啟動時會自動檢測 CPU 是否支持 SYSENTER 指令，從而根據(jù)情況選擇相應(yīng)的系統(tǒng)調(diào)用方式。

1.3.3 SYSENTER 指令誕生故事

介紹完了 SYSENTER 指令的優(yōu)越之處，我們回過頭再來聊聊它的由來。

從 Linux 2.5 內(nèi)核開始，在經(jīng)歷了多方測試、多次 Patch 之后，SYSENTER 指令才正式被 Linux 2.6 版本支持，且由 Linus Torvalds 大神親自操刀實現(xiàn)。

上面提到過，其實早在 1998 年，SYSENTER 指令就已經(jīng)引入到 Intel Pentium II CPU 中，直到 2002 年才在 Linux 2.5 版本的內(nèi)核中出現(xiàn)。該指令一出現(xiàn)，Linux 社區(qū)就開始了激烈討論。

后來 Intel Pentium 4 CPU 發(fā)布了，這款 CPU 在“設(shè)計上存在的問題，造成 Pentium 4 使用中斷方式執(zhí)行系統(tǒng)調(diào)用比 Pentium 3 以及 AMD Athlon 所耗費的 CPU 時鐘周期多 5~10 倍”，Linus 對這個結(jié)果接受不了，于是在 Linux 2.6 內(nèi)核中加入了 SYSENTER 指令，從而實現(xiàn)了更加高效的系統(tǒng)調(diào)用。

這里總結(jié)下系統(tǒng)調(diào)用的執(zhí)行過程。進程從用戶模式轉(zhuǎn)入核心模式，開始執(zhí)行內(nèi)核中實現(xiàn)特定功能的代碼段，執(zhí)行完成后再切回用戶模式，并把執(zhí)行結(jié)果返回給調(diào)用進程。在 Linux 2.4 版本之前，主要利用中斷方式實現(xiàn)核心模式的切換;Linux 2.6 及以后版本的內(nèi)核中，可以利用更高效的 SYSENTER 指令實現(xiàn)。

1.4 系統(tǒng)調(diào)用的標(biāo)準(zhǔn)使用方法

前面提到，本課程所說的系統(tǒng)調(diào)用，默認(rèn)是指 glibc 中的包裝函數(shù)。這些函數(shù)會在執(zhí)行系統(tǒng)調(diào)用前設(shè)置寄存器的狀態(tài)，并仔細檢查輸入?yún)?shù)的有效性。系統(tǒng)調(diào)用執(zhí)行完成后，會從 EAX 寄存器中獲取內(nèi)核代碼執(zhí)行結(jié)果。

內(nèi)核執(zhí)行系統(tǒng)調(diào)用時，一旦發(fā)生錯誤，便將 EAX 設(shè)置為一個負(fù)整數(shù)，包裝函數(shù)隨之將這個負(fù)數(shù)去掉符號后，放置到一個全局的 errno 中，并返回 −1。若沒有發(fā)生錯誤，EAX 將被設(shè)置為 0，包裝函數(shù)獲取該值后，并返回 0，表示執(zhí)行成功，此時無需再設(shè)置 errno。

綜上，系統(tǒng)調(diào)用的標(biāo)準(zhǔn)使用方法可總結(jié)為：根據(jù)包裝函數(shù)返回值的正負(fù)，確定系統(tǒng)調(diào)用是否成功。如果不成功，進一步通過 errno 確定出錯原因，根據(jù)不同的出錯原因，執(zhí)行不同的操作;如果成功，則繼續(xù)執(zhí)行后續(xù)的邏輯。代碼示例如下：

int ret = syscallx(...); 
if(ret < 0) 
{ 
 //有錯誤了，通過 errno 確定出錯的原因，執(zhí)行不同的操作 
} 
else 
{ 
 //調(diào)用成功，繼續(xù)干活 
} 

大多數(shù)系統(tǒng)調(diào)用都遵循這一過程，errno 是一個整數(shù)，可以用 perror 或 strerror 獲得對應(yīng)的文字描述信息。

不過，也有幾個特殊的系統(tǒng)調(diào)用，和上述使用方法存在些許差異。比如，其中有個函數(shù)會在調(diào)用之前將 errno 重置為 0，調(diào)用后，通過檢查 errno 判斷執(zhí)行是否成功。此類函數(shù)只有非常少數(shù)的幾個，使用之前，看看幫助頁，就知道如何使用了。

系統(tǒng)調(diào)用的使用規(guī)范就介紹到這里。此時，你可能有個疑問，每個系統(tǒng)調(diào)用失敗后都會設(shè)置 errno，如果在多線程程序中，不同線程中的系統(tǒng)調(diào)用設(shè)置的 errno 會不會互相干擾呢?

如果 errno 是一個全局變量，答案是肯定的。如果真是這樣的話，那系統(tǒng)調(diào)用的局限性也就太大了，總不能在每個系統(tǒng)調(diào)用之前都加鎖保護吧。優(yōu)秀的 Linux 肯定不會這么弱，那么，這個 errno 的問題又是怎么解決的呢?

1.5 errno 的多線程問題

根據(jù) man 手冊，要使用 errno，首先需要包含 errno.h 這個頭文件。我們先看看 errno.h 里面有什么東西。

vim /usr/include/errno.h 

執(zhí)行以上代碼，會發(fā)現(xiàn)該文件中有這樣幾行關(guān)鍵內(nèi)容：

#include <bits/errno.h> 
....... 
#ifndef errno 
extern int errno; 
#endif 

根據(jù)官方提供的代碼注釋，bits/errno.h 中應(yīng)該有一個 errno 的宏定義。如果沒有，則會在外部變量中尋找一個名為 errno 的整數(shù)，它自然也就成了全局整數(shù)。否則，這個 errno 只是一個 per-thread 變量，每個線程都會拷貝一份。

關(guān)于 per-thread 變量更詳細的信息，我們會在后面的課程中介紹?，F(xiàn)在，你只需知道，這個 errno，每個線程都會獨立拷貝一份，所以在多線程程序中使用它是不會相互影響的。

1.5.1 實現(xiàn)原理

具體是怎么做到的呢?我們可以再打開 bits/errno.h 看一眼。

<bits/errno.h> 
# ifndef __ASSEMBLER__ 
extern int *__errno_location (void) __THROW __attribute__ ((__const__)); 
# if !defined _LIBC || defined _LIBC_REENTRANT 
# define errno (*__errno_location ()) 
# endif 
# endif  

原來，當(dāng) libc 被定義為可重入時，errno 就會被定義成一個宏，該宏調(diào)用外部 __errno_location 函數(shù)返回的內(nèi)存地址中所存儲的值。在 GCC 源碼中，我們還發(fā)現(xiàn)一個測試用例中定義了 __errno_location 函數(shù)的 Stub，是這樣寫的：

extern __thread int __libc_errno __attribute__ ((tls_model ("initial-exec"))); 
int * __errno_location (void) 
{ 
 return &__libc_errno; 
} 

這一簡單的測試用例充分展現(xiàn)了 errno 的實現(xiàn)原理。errno 被定義為 per-thread(用 __thread 標(biāo)識的線程局部存儲類型)變量 __libc_errno，之后 __errno_location 函數(shù)返回了這個線程局部變量的地址。所以，在每個線程中獲取和設(shè)置 errno 的時候，操作的是本線程內(nèi)的一個變量，不會與其他線程相互干擾。

至于 __thread 這個關(guān)鍵字，需要在很“嚴(yán)苛”的條件下才能生效——需要 Linux 2.6 以上內(nèi)核、pthreads 庫、GCC 3.3 或更高版本的支持。不過，放到今天，這些條件已成為標(biāo)配，也就不算什么了。

1.5.2 注意事項

上面只是解釋了在多線程中使用系統(tǒng)調(diào)用時，errno 不會發(fā)生沖突問題，但并不是說所有的系統(tǒng)調(diào)用都可以放心大膽地在多線程程序中使用。

有一些系統(tǒng)調(diào)用，標(biāo)準(zhǔn)中并沒有規(guī)定它們的實現(xiàn)必須是多線程安全的(或者說可重入的，后面的課程中再詳細解釋)。由于歷史原因和實現(xiàn)原理上的限制，有些函數(shù)的實現(xiàn)并不是線程安全的，比如 system()。某些 glibc 函數(shù)也是一樣，比如 strerror 函數(shù)，其內(nèi)部使用一塊靜態(tài)存儲區(qū)存放 errno 描述性信息，最近的一次調(diào)用會覆蓋上一次調(diào)用的內(nèi)容。

glibc 還額外為一些函數(shù)提供了多線程安全實現(xiàn)版本，大多數(shù)是在原函數(shù)名后加上 _r 后綴，比如一些時間操作類的函數(shù)。實現(xiàn)原理是讓應(yīng)用單獨提供緩沖區(qū)，而不再使用同一塊靜態(tài)緩沖區(qū)。更多細節(jié)信息，后面講到線程時，再詳細展開。

1.6 總結(jié)

我們先從總體上認(rèn)識了 Linux 系統(tǒng)調(diào)用，概要地介紹了系統(tǒng)調(diào)用的執(zhí)行過程。還順帶介紹了 Linux 系統(tǒng)調(diào)用方式的發(fā)展小歷史。

隨后，我們介紹了使用系統(tǒng)調(diào)用的標(biāo)準(zhǔn)套路，順帶深入探究了 errno 的多線程解決方法。

希望這些內(nèi)容對你當(dāng)前的工作有所啟發(fā)。最后再說一句，Linux 系統(tǒng)開發(fā)者，一定要多查看 Linux 幫助文檔。