系统编程是什么

系统编程：从抽象接口到物理实现

说起Unix编程的历史，其实并没有严格的“系统”与“应用”之分。即便是开发像X Window这样复杂的图形界面，也都是在系统级（system-level）上进行的，开发者需要直面整个系统的API。而到了现代，操作系统编程才逐渐分化出所谓的“系统级编程”，它使用一套与“应用编程”不同的API（System programming API）。

单从编程的形式和耗费的心力来看，系统编程与应用编程并没有本质的差别。这意味着，一位经验丰富的应用程序员转向系统编程，门槛其实并不算高。那么，两者的核心区别究竟在哪里呢？

首先，系统编程离硬件更近。系统程序员必须对硬件环境和操作系统环境了如指掌。相比之下，应用程序员则更多地是熟悉应用本身的环境。其次，两者使用的函数库和调用方法也存在差异。例如，系统编程在调用系统调用（syscall）时，采用的是所谓的“陷入”机制，也就是软中断方式。

近年来，随着计算应用的不断深化，应用编程确实有逐渐远离底层系统的趋势。但是，这绝不意味着系统编程的末日即将到来。道理很简单：有人用Ja vaScript或C#编写高级应用，就必须有人去编写它们的解释器和运行时环境。更何况，操作系统内核本身的代码，只能通过系统级编程来完成。

系统编程的核心三要素

要进行Linux系统编程，必须熟悉三大块内容：系统调用、C库和C编译器。这三者构成了系统编程的基石。

系统调用（System Calls）

简单来说，系统调用就是用户空间程序与内核进行对话的函数接口，目的是为了向内核请求服务和资源。与其他许多操作系统相比，Linux实现的系统调用数量要精简得多。例如，Linux为i386体系结构实现了大约300个系统调用，而据传Microsoft Windows的系统调用数量则数以千计。当然，Linux内核在不同硬件平台上的实现会有些许差异，但大约90%的系统调用是共通的。

出于安全等因素的考虑，应用程序的代码是不能直接调用内核函数的。它必须通过一种特殊的“陷入”（trap）机制。你可以把它理解为一种“知会”内核工作的特殊函数调用方式（从系统论的角度看，这种较弱的耦合方式也很有意思）。具体如何“陷入”，则因处理器体系结构而异。以i386为例，应用程序通过触发软中断指令（int 0x80）来发起系统调用。那么，0x80代表什么呢？是中断向量号吗？答案是否定的。应用程序必须通过处理器的寄存器来告诉内核要调用哪个服务以及参数是什么。比如，调用`open()`函数时，需要将eax寄存器设置为5，然后把实际的参数放在另外五个寄存器：ebx, ecx, edx, esi和edi中（这也意味着Linux的系统调用最多支持五个参数）。这些寄存器中保存的是用户空间的地址，指向实际的参数数据。

不过，作为一名系统程序员，你通常不需要直接干预这个过程。因为整个调用流程是由硬件体系结构定义的，并且由C库和C编译器自动处理好了。

C库（The C Library）

C库是所有UNIX类系统上应用程序的核心。无论你使用Python、Ja va还是其他任何高级语言，你的代码最终都会调用到C库。其他语言的运行时库，本质上都是构建在C库之上，或者说，是对C库功能的一层包装。在现代Linux系统中，使用的C库是GNU libc，也就是大家常说的glibc。glibc不仅仅是一个遵循C标准的程序语言库，它更是一个强大的系统库，一个现代操作系统的库，其函数涵盖了系统调用的包装、线程支持、底层内存管理、网络支持等诸多方面。

C编译器（The C Compiler）

在Linux世界，C编译器的代名词就是gcc。最初，gcc代表GNU C Compiler，是cc编译器在GNU项目下的实现。如今，gcc已扩展为GNU Compiler Collection，但它仍然是编译C代码的主要入口。在Unix系统（包括Linux）中，编译器与系统编程的关系异常紧密，因为编译器负责实现C语言标准，同时也负责生成符合特定系统ABI（应用二进制接口）的代码，这直接关系到程序能否正确运行。

API与ABI：逻辑约定与物理实现

每个开发者都希望自己编写的程序具有良好的可移植性，能够在不同的软件平台（如操作系统）、硬件平台（如CPU架构）甚至不同的开发版本上运行。影响可移植性的因素很多，其中有两组关键的“系统接口”至关重要：一组是应用编程接口（API），另一组是应用二进制接口（ABI）。

API：源码级的逻辑约定

API是两份软件在源代码级别的接口契约。通过这个标准化的接口（通常以头文件和函数原型的形式提供），客户代码（通常是更上层的软件）可以调用服务代码（通常是更底层的软件，如操作系统或库）的功能。

系统论视角下的接口
接口或端口（port），是处于两个子系统边界上进行信息交换的规格或约定方式。通俗地理解，它定义了信息交换的格式。

应用编程接口
应用编程接口，就是软件系统不同组成部分衔接的约定。由于现代软件规模日益庞大，常需将复杂系统划分为小的组成部分，编程接口的设计就显得尤为重要。良好的接口设计能够合理划分系统职责，提高各组成部分的内聚性，降低它们之间的耦合度，从而提升系统的可维护性和可扩展性。

API本身是抽象的，它只定义了“做什么”，而不涉及“怎么做”。因此，清晰地区分接口定义和接口的具体实现非常重要。例如，C标准库是一个API规范，而uclibc或musl-libc则是它的具体实现；同样，POSIX标准是一个操作系统API规范，而glibc就是它在Linux上的一个主要实现。

那么，API通常包含哪些函数呢？这是个有趣的问题。像C标准库这样的语言库，必须保持高度通用，因此其接口函数不能依赖于特定的软件或硬件特性。相反，POSIX作为操作系统标准，其通用性就相对弱一些，会包含更多与系统管理相关的接口。

ABI：二进制级的物理约定

如果说API是源码级别的、逻辑上的约定，那么ABI就是二进制级别的、物理上的实现约定。它定义了在特定的硬件架构上，两个二进制软件模块（如一个应用程序和一个共享库）之间如何交互的具体细节。这套“物理实现约定”保证了二进制代码的兼容性，也就是说，一段编译好的目标代码，可以在任何遵循相同ABI的系统上直接运行，而无需重新编译源代码。

ABI涵盖的内容非常具体且底层，包括：调用约定（函数参数如何传递、返回值放在哪里、哪些寄存器由调用者保存、哪些由被调用者保存）、字节序（大端还是小端）、寄存器的使用约定、系统调用的具体实现方式、目标文件的链接格式、程序库的行为以及可执行文件的二进制格式等。以调用约定为例，它精确规定了函数如何被调用，参数按什么顺序、通过栈还是寄存器传递，哪些寄存器必须保留原值，以及调用者如何获取返回值。

虽然历史上曾有过为特定架构（尤其是i386）上的不同Unix系统定义一个统一ABI的尝试，但至今未能成功。现实情况是，包括Linux在内的各个操作系统都定义了自己的一套ABI，而这些ABI与硬件架构紧密绑定。大部分ABI规范都涉及机器级别的概念，比如特定寄存器的用途或某条汇编指令的行为。因此，在Linux世界里，我们通常直接用机器架构的名称来指代其ABI，例如“x86-64 ABI”或“ARM ABI”。

Linux编程概念、POSIX与系统库

所有的Unix系统，包括Linux，都提供了一套共同的抽象和接口集合。正是这套共同点定义了什么是“Unix”。例如，对文件、进程、线程的抽象，以及管理管道、套接字、信号的接口等等，这些都是Unix哲学和核心能力的体现。

综上所述，系统编程与应用编程的一个根本区别在于：它们所调用的接口层次和性质不同。系统编程更贴近由ABI和操作系统内核直接提供的底层接口，而应用编程则更多地工作在由API构建的高级抽象层之上。