直接查内核源码中的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 显示的是当前运行内核所支持的系统调用列表 —— 但它只包含上游主线已合入的调用，不包含你本地手动添加但尚未编译进内核的调用。

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

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• 如果重启后 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() 调用就会静默失败。