关于syscall与系统调用包装器可移植性的技术问询

• 系统调用号的平台差异：不同操作系统（如Linux、FreeBSD）或同一系统的不同架构（x86_64、ARM64），同一功能对应的系统调用号往往不同。直接调用syscall()需要手动指定调用号，换平台后必然失效；而libc提供的包装器（如open()、read()）会自动适配当前平台的正确调用号，无需开发者手动处理。
  举个例子：Linux x86_64上open的系统调用号是2，ARM64上是56，FreeBSD上又是另一个数值。直接写syscall(2, path, flags, mode)在ARM64设备上会调用错误的系统调用，而open(path, flags, mode)包装器内部会自动匹配对应架构的调用号。

• 参数传递规范的适配：不同CPU架构的系统调用参数传递规则差异很大——x86架构用栈传参，x86_64用rdi/rsi等寄存器传参，ARM架构有自己的寄存器使用约定。直接调用syscall()必须严格遵守目标架构的传参规则，换架构后代码会直接崩溃；包装器则已经封装了这些底层细节，开发者只需要按标准C函数的方式传参即可。

• 系统调用接口的兼容处理：操作系统版本迭代时，可能会修改系统调用的参数结构、返回值语义，甚至替换为全新的系统调用。包装器会在用户态做兼容适配，比如旧版本的stat()包装器可能会调用新版本的statx()系统调用并转换参数，保证上层代码无需修改即可正常运行；而直接调用syscall()的代码，一旦系统调用接口变更，会直接失效。

• 错误处理的一致性：系统调用包装器会统一处理错误逻辑，比如将系统调用返回的错误码转换为errno并设置，返回-1表示失败；而直接调用syscall()时，不同平台的错误返回规则可能不同，开发者需要手动处理这些差异，增加了跨平台维护的成本。

• 底层实现细节的隐藏：很多系统功能的底层实现在不同平台有差异，包装器会抹平这些差异。比如malloc()底层可能调用brk()或mmap()，不同系统的最优实现方式不同，包装器会自动选择兼容且高效的路径，开发者无需关心这些底层细节。

内容的提问来源于stack exchange，提问作者caitlin wardle