系统调用通过软中断（如syscall指令）进入内核，经sys_call_table跳转至对应处理函数；glibc封装隐藏部分调用（如fopen→openat、getpid缓存），vdso加速time相关调用，新增系统调用需改三处且不推荐。
系统调用到底走的是哪条路径？
用户态程序调用 open() 或 read() 时，并不直接进入内核代码，而是触发软中断（x86 是 int 0x80，现代 x86-64 更常用 syscall 指令），跳转到内核预设的入口函数 sys_call_table 对应的处理函数，比如 sys_open()。这条路径是硬编码在内核镜像里的，不是动态注册的。
常见错误现象：strace ls 显示大量 openat(…) 却找不到对应用户代码里的 fopen() —— 因为 glibc 把 fopen() 实现为对 openat() 的封装，且默认启用 AT_FDCWD；别在用户代码里硬写汇编去调 int 0x80，glibc 已经做了 ABI 适配和错误码转换。
-
syscall指令比int 0x80快，但仅限 x86-64；i386 上仍得用后者 - 系统调用号在不同架构上不通用：比如
write在 x86-64 是 1，在 arm64 是 64 - 内核配置
CONFIG_IA32_EMULATION关闭时，32 位程序在 64 位内核上会直接ENOSYS
怎么自己加一个系统调用？（以 linux 5.15+ 为例）
不推荐。主线内核已冻结新增系统调用接口，除非是硬件驱动强依赖的底层功能（如新 CPU 的安全扩展）。绝大多数需求应该走 /dev 字符设备、ioctl、netlink 或 eBPF。
如果真要实验：必须同时改三处——头文件 arch/x86/entry/syscalls/syscall_64.tbl 加编号和函数名，include/linux/syscalls.h 声明函数原型，再在 fs/read_write.c 或新建文件里实现 sys_my_syscall()。漏掉任一环都会导致链接失败或运行时 ENOSYS。
- 新系统调用函数签名必须以
asmlinkage long开头，参数不超过 6 个，类型受限（不能传结构体指针，需用copy_from_user()） - 返回值必须是
long，负数表示错误（如-EINVAL），正数或 0 才是成功 - 编译后需重装内核并重启，
systemctl reboot不等于热加载
strace 看不见的调用：哪些系统调用被 libc 隐藏了？
strace 默认只显示“裸”系统调用，但 glibc 大量内部优化会让某些行为完全不经过内核——比如小块内存分配用 brk()，但后续 malloc() 分配可能复用堆内存，根本不触发任何系统调用；又比如 getpid() 在多数场景下直接读取 TLS 中缓存的 pid，连 syscall 指令都不发。
常见误解：看到 printf() 没触发 write() 就以为出 bug —— 实际是输出被行缓冲或全缓冲，内容还在用户态 FILE 结构体的缓冲区里。
- 用
strace -e trace=%all强制显示所有，但性能开销极大，别在生产环境跑 -
gettimeofday()在 2.6.29+ 内核中已被 vDSO 替代，strace完全看不到它进内核 -
clock_gettime(CLOCK_MONOTONIC, ...)同样走 vDSO，除非时钟源切换导致回退到真实系统调用
为什么 fork() 和 vfork() 行为差异这么大？
根本区别不在“是否拷贝页表”，而在于内存执行权的让渡时机：fork() 返回后父子进程可并发执行；vfork() 要求子进程必须先调 execve() 或 _exit()，否则父进程被挂起 —— 这是 POSIX 强制语义，不是优化技巧。
容易踩的坑：在 vfork() 后调 printf()、malloc() 或任何可能修改父进程数据的函数，结果未定义；GCC 甚至可能把局部变量优化到寄存器，导致子进程 execve() 失败后父进程恢复时读到垃圾值。
- 现代 glibc 中
vfork()已基本等价于fork()+membarrier()，但语义约束仍在 -
clone()是更底层接口，fork()和vfork()都是它封装，但普通代码不该直接用clone() - 容器场景下
fork()触发 COW，若父进程有大堆内存，首次写入延迟明显；vfork()可规避，但风险极高
事情说清了就结束。系统调用不是 API 文档里那几行声明，它是用户态和内核态之间一道有状态、有缓存、有 ABI 约束、还带硬件特性的窄门。越想绕过它，越容易撞上 vDSO、COW、seccomp 或 ptrace 的边界。