系统调用、符号版本与数据结构演进：FreeBSD 如何处理兼容性
内容提要
FreeBSD通过libc符号版本、系统调用兼容层及ioctl结构体处理维持ABI稳定。旧程序依赖旧接口，内核保留freebsd11_*等兼容代码转换数据结构；新用户态对旧内核则逐接口回退，如getentropy()。兼容代码随时间累积，但终会因使命完成而删除，体现ABI稳定的工程代价。
延伸解读
ABI稳定的工程代价
FreeBSD的ABI稳定并非抽象承诺，而是通过libc符号版本、内核兼容系统调用和ioctl结构体处理等具体手段实现。这些兼容代码往往繁琐且难以删除，如freebsd11_*接口和getentropy()的回退逻辑。它们虽不美观，却是维持旧程序运行的必要代价，体现了工程上的权衡。
libc符号版本与弱符号的区别
libc的ELF符号版本机制允许新旧ABI并存，动态链接器根据符号版本为旧程序匹配旧实现，而弱符号则用于可覆盖的默认实现，如pthread桩函数。两者解决不同问题：符号版本处理不兼容变化，弱符号处理可覆盖性。理解这一区别有助于正确设计兼容策略。
新用户态与旧内核的兼容策略
FreeBSD通常不保证新版world与旧内核任意搭配，但libc会为特定接口提供回退，如getentropy()在getrandom(2)返回ENOSYS时改用kern.arandom sysctl。这种兼容是逐接口实现的，并非全局属性，且当所有受支持版本都提供新接口后，回退代码会被删除，体现兼容代码的生命周期。
ioctl结构体设计的教训
ioctl请求编号编码了参数大小，结构体变化会导致新旧请求不匹配，从而调用失败。为避免ABI问题，跨边界结构体应预留保留字段，并考虑显式版本字段或长度判断。ZFS的zfs_iocparm_t包装结构就是通过版本转换代码处理结构体演进的例子，说明提前设计的重要性。
Q&A
FreeBSD如何通过libc符号版本机制保持ABI稳定？
FreeBSD的libc使用ELF符号版本机制，将不同开发周期加入的ABI放入不同的FBSD_1.x符号命名空间，并通过Versions.def声明。这样，同一个共享库可以同时保留某个接口的新旧实现，动态链接器根据旧二进制文件记录的符号版本，找到对应的ABI版本，从而让新旧程序都能正确运行。
FreeBSD如何处理新用户态与旧内核的兼容性？
FreeBSD通常不保证新版world与旧内核任意搭配，但某些libc接口会为旧内核提供回退机制。例如，getentropy()在getrandom(2)返回ENOSYS时，会回退到旧内核的kern.arandom sysctl。这种兼容是针对每个接口逐一实现的，并非全局属性。
FreeBSD如何通过系统调用兼容层支持旧程序在新内核上运行？
FreeBSD保留旧ABI的系统调用入口，如freebsd11_*系列，这些兼容层负责将旧用户态结构转换为当前内核内部结构。例如，freebsd11_stat()调用kern_statat()，然后将结果转换为旧struct stat并copyout给用户态。这样，核心文件系统代码只使用当前数据结构，而兼容层处理历史ABI。
FreeBSD的ioctl如何处理结构体大小变化带来的ABI问题？
FreeBSD的ioctl编号中编码了参数方向和大小，因此结构体大小变化会导致请求编号不同，从而避免内核和用户态在不知情的情况下交换错误数据。但驱动仍需决定是否支持旧请求编号、新旧结构体转换等。例如，OpenZFS在FreeBSD上使用固定大小的包装结构zfs_iocparm_t，内含ABI版本字段和指针，内核中维护版本转换代码。
FreeBSD的兼容代码为什么难以删除？
兼容代码一旦成为ABI的一部分，就很难删除，因为旧程序可能仍在依赖它们。例如，arc4random_stir()被删除后，仍保留兼容桩并记录日志。兼容代码会随时间累积，但最终当所有受支持版本都提供新接口时，也会被删除，如getentropy()的回退逻辑在2024年被移除。
FreeBSD如何处理旧ABI中inode编号超出范围的情况？
FreeBSD通过vfs.ino64_trunc_error sysctl控制行为：默认静默截断超出范围的值，管理员也可选择返回EOVERFLOW错误或限制为旧类型最大值。这用于在旧ABI无法表示新值时明确告知程序接口过旧。
