Linux驱动适配内核时，对于不同版本内核中有变化函数的适配方式

一、情景

Linux驱动适配不同内核时，由于内核版本的不同，有些函数可能没有，或者在高版本中函数已经变化了，比如增删了一些参数。

二、常规处理方案，根据内核版本判断

一般情况我们处理方式是在使用这些函数时，通过宏来判断当前的内核版本，根据版本来决定怎么正确的使用函数，比如：

#if LINUX_VERSION_CODE < KERNEL_VERSION(5,12,0)
		generic_fillattr(inode, stat);
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5,12,0) && LINUX_VERSION_CODE < KERNEL_VERSION(6,3,0)
		generic_fillattr(mnt_userns, inode, stat);
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(6,3,0) && LINUX_VERSION_CODE < KERNEL_VERSION(6,6,0)
		generic_fillattr(idmap, inode, stat);
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(6,6,0)
		generic_fillattr(idmap,request_mask,inode, stat);
#endif

这种我们需要准确知道generic_fillattr这个函数在哪个内核版本怎么变化了。但是Linux的内核有那么多，要找到从哪个版本开始变化的，很多时候需要巨大的工作量。
另外目前国产Linux内核的版本管理有些比较混乱，会出现版本号完全不能代表其使用的函数接口的问题，所以更迫切的需要编译时准确的判断使用哪个函数接口。

根据版本号判断还解决不了发行版回溯的问题

上游变更：从 Linux 6.4 起，kallsyms_on_each_symbol 去掉了 module 参数，回调从 (void*, const char*, struct module*, unsigned long) 变成了 (void*, const char*, unsigned long)。
企业发行版的回溯：Alma/RHEL 9（5.14 系列）经常把上游新特性/改动回溯到旧版本内核。于是实际运行内核可能已经使用“3 参数”回调，而你的模块按“4 参数”编译（或反之）。
结果：内核按 3 参数调用回调，你的函数按 4 参数取参，导致把“addr”错读成第四个参数位置上的垃圾/常量；或者把“module”错当 addr。于是你看到 rc=0、addr 不为 NULL，但所有符号的 addr 全是同一个常量（ffffffffa2a00000），永远“成功但错误”。

三、以vfs_getattr函数为例，介绍推荐的处理方案——编译时测试并决定

Linux的驱动适配，我们都需要在对应适配的内核中去编译一次，基于这个原理，我们可以在编译时，通过测试脚本，来确定使用的函数在当前内核中是否存在，以及是怎么样的形式存在。

不同内核版本的vfs_getattr

低版本内核中，接受三个参数：

int vfs_getattr(struct vfsmount *mnt, struct dentry