2. 系统调用编号：系统调用号的定义、在x86_64架构中的分配、sys_ni_syscall的作用

系统调用编号（syscall number）是用户态与内核态之间进行服务请求的唯一标识符。每个系统调用在全局范围内被分配一个固定的整数编号，内核通过该编号在系统调用表中索引对应的处理函数。本章深入分析系统调用号的定义机制、在x86_64架构中的分配策略，以及空操作函数 sys_ni_syscall 的设计意图。

2.1 系统调用号的定义与数据结构

在Linux内核中，系统调用号通过枚举类型或宏定义在架构相关的头文件中声明。对于x86_64架构，系统调用号定义在 arch/x86/include/generated/uapi/asm/unistd_64.h 文件中（由构建系统自动生成）。每个系统调用号对应一个唯一的宏常量，其值从0开始递增。

// x86_64 系统调用号定义示例（简化）
#define __NR_read              0
#define __NR_write             1
#define __NR_open              2
#define __NR_close             3
#define __NR_stat              4
#define __NR_fstat             5
// ... 后续编号依次递增
#define __NR_execve            59
#define __NR_exit              60
#define __NR_clone             56
// 最大系统调用号通常为 __NR_syscall_max

系统调用表在 arch/x86/kernel/syscall_64.c 中定义，其声明方式如下：

// 系统调用表声明（x86_64）
asmlinkage const sys_call_ptr_t sys_call_table[__NR_syscall_max+1] = {
    [0 ... __NR_syscall_max] = &sys_ni_syscall,
#include <asm/syscalls_64.h>
};

上述代码的关键设计点：

• 数组初始化：使用GCC扩展语法 [0 ... __NR_syscall_max] 将所有表项初始化为 sys_ni_syscall 的地址。
• 头文件包含：#include <asm/syscalls_64.h> 会展开为一系列指定系统调用号的初始化项，覆盖默认的空操作函数。
• 类型定义：sys_call_ptr_t 是一个函数指针类型，指向接收 struct pt_regs * 参数并返回 long 的函数。

2.2 x86_64架构中的系统调用号分配策略

x86_64架构对系统调用号的分配遵循一套严格的规则，以确保兼容性和可扩展性。下表总结了不同编号范围的用途：

编号范围	用途	说明
0 – 299	标准系统调用	覆盖POSIX、Linux特有及常用系统调用，如 read(0)、write(1)、open(2)
300 – 399	扩展系统调用	用于较新添加的系统调用，如 epoll_create1(291)、accept4(288)
400 – 499	预留/架构特定	部分架构使用此范围实现特定功能，x86_64当前未大量使用
500 – 599	未来扩展	为未来系统调用预留，当前映射到 sys_ni_syscall
≥ 600	未使用	超出当前定义范围，访问将返回 -ENOSYS

在x86_64中，系统调用号通过 rax 寄存器从用户态传递到内核态。内核入口代码（entry_64.S）从 rax 中读取编号，并检查其是否在有效范围内：

// x86_64 系统调用入口中的编号检查（简化伪代码）
entry_SYSCALL_64:
    // rax 包含系统调用号
    cmpq    $__NR_syscall_max, %rax
    ja      return_ENOSYS       // 超出范围，返回 -ENOSYS
    // 从 sys_call_table 中获取处理函数
    movq    sys_call_table(, %rax, 8), %rax
    // 调用处理函数
    call    *%rax

2.3 sys_ni_syscall 的作用与实现

sys_ni_syscall 是内核中一个特殊的“空操作”系统调用处理函数。它的名称来源于“not implemented”（未实现）。该函数的作用是处理那些没有实际实现或已被废弃的系统调用号。

sys_ni_syscall 的实现极其简洁：

// kernel/sys_ni.c
asmlinkage long sys_ni_syscall(void)
{
    return -ENOSYS;
}

该函数在以下场景中发挥关键作用：

• 系统调用表初始化：所有未显式赋值的表项默认指向 sys_ni_syscall，保证表访问的安全性。
• 废弃系统调用：当某个系统调用被移除（如 old_umount），其编号保留但实现替换为 sys_ni_syscall。
• 条件编译：当某个功能被内核配置禁用（如 CONFIG_SECCOMP 未启用），对应的系统调用号映射到 sys_ni_syscall。
• 架构差异：不同架构支持的系统调用集合不同，未实现的编号统一指向 sys_ni_syscall。

2.4 系统调用号分配与sys_ni_syscall关系图

下图展示了系统调用号从用户态传递到内核态后，如何通过系统调用表找到对应的处理函数，以及 sys_ni_syscall 在其中的位置：

2.5 系统调用号分配的实际案例

以下是一个实际系统调用号分配的例子，展示从用户态调用到内核处理函数的完整链路：

1. 用户态调用：应用程序调用 write(fd, buf, count)，glibc 封装后执行 syscall 指令，rax 设置为 1（__NR_write）。
2. 内核入口：entry_SYSCALL_64 保存寄存器状态，从 rax 读取系统调用号 1。
3. 编号检查：比较 1 与 __NR_syscall_max（当前约为 450），1 在有效范围内。
4. 表索引：从 sys_call_table[1] 获取函数指针，该位置存储的是 sys_write 的地址。
5. 函数执行：调用 sys_write 执行实际的写操作。

2.6 系统调用号与架构兼容性

不同架构对系统调用号的分配存在差异，x86_64 与 x86_32（ia32）使用不同的编号空间。内核通过 CONFIG_IA32_EMULATION 支持在 x86_64 内核上运行 32 位程序，此时需要维护两套系统调用表：

架构	系统调用表	编号范围	最大编号
x86_64 (64位)	sys_call_table	0 – 449	__NR_syscall_max
x86_32 (ia32兼容)	ia32_sys_call_table	0 – 399	__NR_ia32_syscall_max

这种分离设计确保了 64 位和 32 位程序可以共存，且各自的系统调用号互不干扰。当 32 位程序执行 syscall 或 int 0x80 时，内核根据入口路径选择对应的系统调用表。