來源：https://gitbook.cn/gitchat/column/5bfbbe9b7d496f13396961de/topic/5c21aa444fcd483b0264eb19
本文主要帶大家深入研究 Linux 系統編程。系統編程的任務，可以定義為使用系統提供的功能解決我們面對的實際問題，而系統調用，則是系統開放給應用執行特定功能的接口。本文首先
從 Linux 系統調用講起，主要包括以下內容：- 系統調用概述
- 系統調用的兩種調用方式
- 系統調用的兩種執行過程
- 系統調用的標準使用方法
另外，還會擴展兩個知識點：
- 與早期 Linux 相比，2.6 以後版本的內核，是如何實現更高效的系統調用的？
- 全局 errno 是如何解決多線程衝突問題的？
1.1 系統調用概述
系統調用是操作系統內核提供給應用程序的基礎接口，需要運行在操作系統的核心模式下，以確保有權限執行某些 CPU 特權指令。
Linux 系統提供了功能非常豐富的系統調用，涵蓋了文件操作、進程控制、內存管理、網絡管理、套接字操作、用戶管理、進程間通信等各個方面。
執行如下命令，可列出系統中所有的系統調用名稱。
man syscalls
Linux 自帶的 man 手冊對每個系統調用都進行了非常詳細的說明，包括函數功能、傳入的參數、返回值，以及可能產生的錯誤、使用注意事項，等等，其完善程度絲毫不亞於微軟的 MSDN。雖然是英文版，但讀起來比較通俗易懂，每位 Linux 系統開發者都應該習慣於查看這些文檔。
另外，IBM 文檔庫裡有一份質量非常高的《中文版系統調用列表》，閱讀它會更輕鬆。
1.2 系統調用的兩種調用方式
我們先看第一種方式。
系統調用由指派的編號來標識，通過 syscall 函數以編號為參數可直接被調用。
syscall 函數原型為：
int syscall(int number, ...);
完整的系統調用編號都定義在 sys/syscall.h 文件中。感興趣的讀者可以自行查看。
顯然，記憶如此多的編號，對開發者很不友好。
於是，開發者多會選擇第二種方式，即利用 glibc 提供的包裝函數將這些系統調用包裝成名字自解釋的函數。
這個過程，包裝函數並沒有做太多額外工作，主要是檢查參數，將它們拷貝到合適的寄存器中，接著調用指定標號的系統調用，之後再根據結果設置 errno，供應用程序檢查執行結果，以及其他相關工作。
兩種調用方式，在功能上可以認為是完全等價的，但在易讀、易用性上，glibc 包裝函數則更有優勢。在之後的課程中，我提到某系統調用，若無特殊說明，指的便是 glibc 包裝函數。
當然，如果包裝函數無法滿足某些特殊應用場景需求，還可以使用 syscall 函數直接執行系統調用。不過這種情況非常少見，到目前為止，我還沒有遇到過。
1.3 系統調用的兩種執行過程
1.3.1 基於中斷方式
系統調用的實現代碼是內核代碼的一部分。執行系統調用代碼，首先需要將系統從用戶模式切換到核心模式。
早期的系統調用通過軟中斷實現模式的切換，而中斷號屬於系統稀缺資源，不可能為每個系統調用都分配一箇中斷號。
在 Linux 的實現中，所有的系統調用共用 128 號中斷（也就是大名鼎鼎的 int 0x80 ），其對應的中斷處理程序是 system_call，所有的系統調用都會轉到這個中斷處理程序中。
接著，system_call 會根據 EAX 傳入的系統調用標號跳轉並執行相應的系統調用程序。如果需要更多的參數，會依次用 EBX、ECX、EDX、EDI 進行傳遞。函數執行完成之後，會把結果放到 EAX 中返回給應用程序。
由此可知，一次系統調用便會觸發一次完整的中斷處理過程。在每次中斷處理過程中，CPU 都會從系統啟動時初始化好的中斷描述表中，取出該中斷對應的門描述符，並判斷門描述符的種類。
在確認門描述符的級別（DPL）不比中斷指令調用者的級別（CPL）低之後，再根據描述符的內容，將中斷處理程序中可能用到的寄存器進行壓棧保存。最後執行權限提升，設置 CS 和 EIP 寄存器，以使 CPU 跳轉到指定的系統調用的代碼地址，並執行目標系統調用。
1.3.2 基於 SYSENTER 指令
再仔細審視基於中斷方式的系統調用的執行過程，不難發現，前面很多處理過程都是固定的，其實很沒必要，如門描述符級別檢查、查找中斷處理程序入口，等等。
為了省去這些多餘的檢查，Intel 在 Pentium II CPU 中加入了新的 SYSENTER 指令，專門用來執行系統調用。
該指令會跳過前面檢查步驟，直接將 CPU 切換到特權模式，繼而執行系統調用，同時還增加了幾個專用寄存器輔助完成參數傳遞和上下文保存工作。另外，還相應地增加了 SYSEXIT 指令，用來返回執行結果，並切回用戶模式。
在 Linux 實現了 SYSENTER 方式的系統調用之後，就有人用 Pentium III 的機器對比測試了兩種系統調用的效率。測試結果顯示，與中斷方式相比，SYSENTER 在用戶模式下因省掉了級別檢查類的操作，花費的時間大幅減少了 45% 左右；在核心模式下，因少了一個寄存器壓棧保存動作，所花費的時間也減少了 2% 左右 。
目前，基於中斷方式的系統調用仍然保留著，Linux 啟動時會自動檢測 CPU 是否支持 SYSENTER 指令，從而根據情況選擇相應的系統調用方式。
1.3.3 SYSENTER 指令誕生故事
介紹完了 SYSENTER 指令的優越之處，我們回過頭再來聊聊它的由來。
從 Linux 2.5 內核開始，在經歷了多方測試、多次 Patch 之後，SYSENTER 指令才正式被 Linux 2.6 版本支持，且由 Linus Torvalds 大神親自操刀實現。
上面提到過，其實早在 1998 年，SYSENTER 指令就已經引入到 Intel Pentium II CPU 中，直到 2002 年才在 Linux 2.5 版本的內核中出現。該指令一出現，Linux 社區就開始了激烈討論。
後來 Intel Pentium 4 CPU 發佈了，這款 CPU 在“設計上存在的問題，造成 Pentium 4 使用中斷方式執行系統調用比 Pentium 3 以及 AMD Athlon 所耗費的 CPU 時鐘週期多 5~10 倍”，Linus 對這個結果接受不了，於是在 Linux 2.6 內核中加入了 SYSENTER 指令，從而實現了更加高效的系統調用。
最後總結下系統調用的執行過程。進程從用戶模式轉入核心模式，開始執行內核中實現特定功能的代碼段，執行完成後再切回用戶模式，並把執行結果返回給調用進程。在 Linux 2.4 版本之前，主要利用中斷方式實現核心模式的切換；Linux 2.6 及以後版本的內核中，可以利用更高效的 SYSENTER 指令實現。
想了解更詳細的技術細節，大家可以閱讀內核代碼，對應的文件是 arch/i386/kernel/vsyscall-sysenter.S。當然，在 glibc 中也需做相應的修改，即把 int 0x80 替換成 call xxxx，xxxx 為執行系統調用的函數地址。1.4 系統調用的標準使用方法
前面提到，本課程所說的系統調用，默認是指 glibc 中的包裝函數。這些函數會在執行系統調用前設置寄存器的狀態，並仔細檢查輸入參數的有效性。系統調用執行完成後，會從 EAX 寄存器中獲取內核代碼執行結果。
內核執行系統調用時，一旦發生錯誤，便將 EAX 設置為一個負整數，包裝函數隨之將這個負數去掉符號後，放置到一個全局的 errno 中，並返回 −1。若沒有發生錯誤，EAX 將被設置為 0，包裝函數獲取該值後，並返回 0，表示執行成功，此時無需再設置 errno。
綜上，系統調用的標準使用方法可總結為：根據包裝函數返回值的正負，確定系統調用是否成功。如果不成功，進一步通過 errno 確定出錯原因，根據不同的出錯原因，執行不同的操作；如果成功，則繼續執行後續的邏輯。代碼示例如下：
int ret = syscallx(...);
if(ret < 0)
{
//有錯誤了，通過 errno 確定出錯的原因，執行不同的操作
}
else
{
//調用成功，繼續幹活
}
大多數系統調用都遵循這一過程，errno 是一個整數，可以用 perror 或 strerror 獲得對應的文字描述信息。
不過，也有幾個特殊的系統調用，和上述使用方法存在些許差異。比如，其中有個函數會在調用之前將 errno 重置為 0，調用後，通過檢查 errno 判斷執行是否成功。此類函數只有非常少數的幾個，使用之前，看看幫助頁，就知道如何使用了。
系統調用的使用規範就介紹到這裡。此時，你可能有個疑問，每個系統調用失敗後都會設置 errno，如果在多線程程序中，不同線程中的系統調用設置的 errno 會不會互相干擾呢？
如果 errno 是一個全局變量，答案是肯定的。如果真是這樣的話，那系統調用的侷限性也就太大了，總不能在每個系統調用之前都加鎖保護吧。優秀的 Linux 肯定不會這麼弱，那麼，這個 errno 的問題又是怎麼解決的呢？
1.5 errno 的多線程問題
根據 man 手冊，要使用 errno，首先需要包含 errno.h 這個頭文件。我們先看看 errno.h 裡面有什麼東西。
vim /usr/include/errno.h
執行以上代碼，會發現該文件中有這樣幾行關鍵內容：
#include <bits>
.......
#ifndef errno
extern int errno;
#endif
/<bits>
根據官方提供的代碼註釋，bits/errno.h 中應該有一個 errno 的宏定義。如果沒有，則會在外部變量中尋找一個名為 errno 的整數，它自然也就成了全局整數。否則，這個 errno 只是一個 per-thread 變量，每個線程都會拷貝一份。
關於 per-thread 變量更詳細的信息，我們會在後面的課程中介紹。現在，你只需知道，這個 errno，每個線程都會獨立拷貝一份，所以在多線程程序中使用它是不會相互影響的。
1.5.1 實現原理
具體是怎麼做到的呢？我們可以再打開 bits/errno.h 看一眼。
<bits>
# ifndef __ASSEMBLER__
extern int *__errno_location (void) __THROW __attribute__ ((__const__));
# if !defined _LIBC || defined _LIBC_REENTRANT
# define errno (*__errno_location ())
# endif
# endif
/<bits>
原來，當 libc 被定義為可重入時，errno 就會被定義成一個宏，該宏調用外部 __errno_location 函數返回的內存地址中所存儲的值。在 GCC 源碼中，我們還發現一個測試用例中定義了 __errno_location 函數的 Stub，是這樣寫的：
extern __thread int __libc_errno __attribute__ ((tls_model ("initial-exec")));
int * __errno_location (void)
{
return &__libc_errno;
}
這一簡單的測試用例充分展現了 errno 的實現原理。errno 被定義為 per-thread（用 __thread 標識的線程局部存儲類型）變量 __libc_errno，之後 __errno_location 函數返回了這個線程局部變量的地址。所以，在每個線程中獲取和設置 errno 的時候，操作的是本線程內的一個變量，不會與其他線程相互干擾。
至於 __thread 這個關鍵字，需要在很“嚴苛”的條件下才能生效——需要 Linux 2.6 以上內核、pthreads 庫、GCC 3.3 或更高版本的支持。不過，放到今天，這些條件已成為標配，也就不算什麼了。
1.5.2 注意事項
上面只是解釋了在多線程中使用系統調用時，errno 不會發生衝突問題，但並不是說所有的系統調用都可以放心大膽地在多線程程序中使用。
有一些系統調用，標準中並沒有規定它們的實現必須是多線程安全的（或者說可重入的，後面的課程中再詳細解釋）。由於歷史原因和實現原理上的限制，有些函數的實現並不是線程安全的，比如 system()。某些 glibc 函數也是一樣，比如 strerror 函數，其內部使用一塊靜態存儲區存放 errno 描述性信息，最近的一次調用會覆蓋上一次調用的內容。
glibc 還額外為一些函數提供了多線程安全實現版本，大多數是在原函數名後加上 _r 後綴，比如一些時間操作類的函數。實現原理是讓應用單獨提供緩衝區，而不再使用同一塊靜態緩衝區。更多細節信息，後面講到線程時，再詳細展開。
1.6 總結
我們先從總體上認識了 Linux 系統調用，概要地介紹了系統調用的執行過程。還順帶介紹了 Linux 系統調用方式的發展小歷史。
隨後，我們介紹了使用系統調用的標準套路，順帶深入探究了 errno 的多線程解決方法。
希望這些內容對你當前的工作有所啟發。最後再說一句，Linux 系統開發者，一定要多查看 Linux 幫助文檔。
閱讀更多 cpp軟件架構獅 的文章
