Linux如何查看具体的内核补丁更新后新增的系统调用及接口详细列表清单

想知道系统调用编号与函数名的硬编码映射关系？直接查内核源码中的syscall_64.tbl（x86_64）或syscall_32.tbl（i386）文件就行。这映射可是在编译时就确定好了的，不是运行时才生成哦。而且，要是想新增系统调用，那对应的tbl文件得修改，声明头文件也不能少，服务函数得实现，内核还得同步编译，这些步骤一个都不能落下。

直接查内核源码里的 syscall_64.tbl（x86_64）或 syscall_32.tbl（i386）

系统调用编号和函数名的映射关系，硬编码在内核源码树里，不是运行时动态生成的。补丁若新增了系统调用，必然要修改对应架构的 syscall_*.tbl 文件。

比如你刚打完一个补丁，想确认它加了哪些新调用：

• 进到解压后的内核源码目录，路径通常是 /usr/src/linux-source-5.x.x/
• 打开 arch/x86/entry/syscalls/syscall_64.tbl（64位系统）或 arch/x86/entry/syscalls/syscall_32.tbl（32位）
• 找行末带新编号（如 436）、函数名非内核原生（如 jkbcall）的条目
• 注意：编号必须唯一且大于已有最大值，否则编译会报 duplicate syscall number

用 man syscalls 看当前内核已知的全部系统调用

man syscalls 显示的是当前运行内核所支持的系统调用列表 —— 但它只包含上游主线已合入的调用，不包含你本地手动添加但尚未编译进内核的调用。

也就是说，这个命令只能验证「补丁是否已成功编译并启动」：

• 如果重启后 man syscalls 里仍没出现你的新调用名，说明内核没真正加载新镜像（vmlinuz 还是旧的）
• 如果 grep -i your_syscall_name /usr/share/man/man2/*.gz 有结果，说明 man page 已随补丁一并安装
• 注意：部分发行版（如 Ubuntu）的 manpages-dev 包才提供 syscall 手册页，没装就查不到

检查 /proc/sys/kernel/osrelease 和实际编译版本是否一致

补丁更新后最常踩的坑：你以为重启进了新内核，其实 GRUB 还默认引导旧内核。

先确认当前跑的是哪个内核：

• uname -r 输出的是当前运行内核版本号（如 5.4.0-122-generic）
• cat /proc/sys/kernel/osrelease 应该和上面完全一致；如果不一致，说明内核模块或符号表错配
• 对比 ls /boot/vmlinuz-* 列出所有可用内核镜像，再看 grubby --default-kernel（RHEL/CentOS）或 grep menuentry /boot/grub/grub.cfg | head -n 5（Ubuntu/Debian）确认默认启动项
• 若发现默认不是你新编译的内核，需执行 sudo update-grub && sudo reboot（Debian系）或 sudo grub2-mkconfig -o /boot/grub2/grub.cfg（RHEL系）

验证新系统调用是否真能被用户态调用

光有编号和声明不够，得实测能否触发。最轻量级方式是用 strace + 自写最小测试程序：

• 写个 C 文件，用 syscall(436)（假设你的新调用号是 436）直接触发，不要依赖 glibc 封装
• 编译时加 -static 避免链接器绕过你的调用
• 运行前先 strace -e trace=436 ./a.out，如果输出 syscall_436() 并返回非 -ENOSYS，说明内核已识别该调用
• 若返回 -ENOSYS，大概率是：内核没加载新镜像、sys_call_table 未正确 patch、或函数实现没放进 kernel/ 目录下被编译进去

真正的难点不在“怎么列出来”，而在于补丁带来的 syscall 编号、头文件声明、函数实现、符号导出这四点必须严格同步；漏掉任意一环，syscall() 调用就会静默失败。