这段时间一直在折腾Accel32在Linux 4.xx内核下的适配工作。Accel32是一张PCIe接口的32通道数据采集加速卡板载FPGA做信号预处理通过DMA和主机交换数据。之前它的驱动一直是基于3.x内核写的构建脚本、接口调用、设备注册方式全是老一套放到4.x内核上编译直接一片报错。这篇就把整个适配过程中遇到的坑、接口迁移明细、以及最后稳定运行的方法完整梳理一遍给同样在做内核适配的同行一个参考。先交代一下使用场景我这边主要用Accel32做工业现场的多通道信号采集比如振动分析、电网波形记录这类对同步性和吞吐量要求比较高的场合。主机平台是x86_64的工控机内核从3.16升级到4.19。LTS版本的内核维护周期长驱动适配一次能管很久所以这次迁移的目标就是4.19当然代码里也做了4.4、4.9、4.14的兼容处理。整个过程下来最大的体会是4.xx内核的改动虽然不像2.6到3.0那次伤筋动骨但API层面的删除力度很坚决老驱动如果不主动跟上基本就是编不过、装不上、跑不起来的命运。下面按我实际操作时的顺序来写从最开始的编译报错到设备枚举、数据通路重建再到多版本兼容和稳定性验证。1. 老驱动在4.xx内核上第一次编译失败五个最直接的硬伤Accel32的旧驱动写于2014年前后当时内核版本还是3.13。直接放到4.19上执行make报错信息将近两百行而且很多错误是一处引发几十个后续连环报错。我处理这类问题有个习惯不从头扫错先抓第一个真实的编译错误修掉再继续编译。重复几轮后真正阻碍编译通过的硬伤大概有五个。1.1 构建脚本里的内核版本判断完全失效旧Makefile里用了这样的判断逻辑ifeq ($(shell test $(KERNELRELEASE) -ge 3.10 echo yes), yes) EXTRA_CFLAGS -DHAVE_NEW_MMAP endif这里的KERNELRELEASE在4.19下是4.19.0-xxx-generic带一串后缀字符串比较根本不是数字比较的结果。测试得到的结果永远是假导致新代码路径全被屏蔽老代码路径又编不过。正确的做法是解析出数字版本号再比较KERNEL_MAJOR : $(shell uname -r | cut -d. -f1) KERNEL_MINOR : $(shell uname -r | cut -d. -f2)这里还需要注意驱动编译必须依赖目标内核的构建目录如果为多个内核版本构建不要使用当前正在运行的uname -r而应该通过KDIR传入目标内核源码路径再从KDIR下的include/config/kernel.release文件读取版本号。例如KDIR ? /lib/modules/$(shell uname -r)/build KREL : $(shell cat $(KDIR)/include/config/kernel.release) KMAJ : $(shell echo $(KREL) | cut -d. -f1) KMIN : $(shell echo $(KREL) | cut -d. -f2)这种取法在主线内核和发行版内核上都能用。写死字符串比较是很多老驱动常见的问题排查时值得第一个看。1.2 驱动入口处的printk级别宏被移动旧代码里用了类似#include linux/version.h然后通过#if LINUX_VERSION_CODE KERNEL_VERSION(3,10,0)来走不同分支。这个思路本身没问题但4.19下很多头文件的包含路径相比3.x调整过。比如UTS_RELEASE这类的定义在4.x里依赖linux/utsname.h或者generated/utsrelease.h。单纯依赖linux/version.h可能会导致编译时找不到某些宏。更常见的报错是关于console_printk或者CONSOLE_LOGLEVEL_DEFAULT。3.x时代可以直接extern引用这些符号4.0以后内核把printk的实现做了整理直接引用会报undefined symbol或者在编译时就提示隐式声明。Accel32驱动里打印环形缓冲状态用到了这一类接口我干脆全部换成pr_info、pr_err和dev_info不再直接操作内核日志级别。1.3 老式挂载方式的file_operations结构体不再被接受4.x内核里字符设备的file_operations成员函数虽然名字没变但内核内部对.owner THIS_MODULE的要求更严格了而且如果驱动用了.ioctl字段编译时会出现-Werrormissing-field-initializers之类的警告在某些内核配置下直接变成错误。另外一个问题是3.x时代很多驱动用.aio_read、.aio_write这类异步接口4.0以后这些接口被移除统一走.read_iter和.write_iter。Accel32旧驱动没走异步IO但我在检查时发现用户态的工具链里有用到libaio的例程这些例程在内核4.x下依然能用因为底层是io_submit加read_iter。如果驱动本身不实现read_iter那么所有pread调用都会走默认的default_file_splice_read路径性能损失明显这一点后面再展开。1.4 timer接口的替换是4.15之后绕不过去的坎Accel32驱动里有两个地方用到了内核定时器一个是看门狗定时一个是DMA超时重试。老写法是init_timer(dev-watchdog_timer); dev-watchdog_timer.function accel32_watchdog_callback; dev-watchdog_timer.data (unsigned long)dev; add_timer(dev-watchdog_timer);4.15内核引入了timer_setup接口同时把data参数去掉由from_timer宏从struct timer_list反推包含它的结构体。新写法是timer_setup(dev-watchdog_timer, accel32_watchdog_callback, 0);回调函数签名也从void (*)(unsigned long)变成了void (*)(struct timer_list *)void accel32_watchdog_callback(struct timer_list *t) { struct accel32_dev *dev from_timer(dev, t, watchdog_timer); // 原逻辑照搬 }这个改动不是单纯改名from_timer宏里用了container_of所以回调里拿到的指针一定是包含timer_list的那个结构体首地址比老式的data指针更安全。我顺便排查了驱动里所有init_timer用法确保没有遗漏。4.19下如果还用init_timer编译直接报错没有过渡期。1.5 并发控制相关API的名称调整3.x时代常用lock_kernel()、unlock_kernel()的驱动在4.x里直接定义都找不到。Accel32驱动没用这些全局锁但它用了semaphore作为用户态IO的互斥量而include/linux/semaphore.h在4.x里的依赖变了。单独引入这个头文件没问题但如果驱动里同时用up()和down_interruptible()4.19下会把down_interruptible标记为已废弃虽然还能编过但会产生警告。我统一改成了mutex_lock_interruptible配合mutex类型。这个改动同样需要仔细检查所有等待唤醒路径避免mutex和waitqueue混用时出现死锁。经过这几轮修补驱动终于能编译成.ko文件了。但是insmod时候立刻遇到第二个问题注册失败提示No such device。这说明编译层面的问题解决了设备枚举层面的问题还没解决。2. 从3.x到4.xAccel32需要迁移的驱动接口明细这节把Accel32驱动里所有做过迁移的内核接口列一个对照表方便其他做老设备适配的人直接对着查。我把这些接口分成五个维度字符设备、proc/sysfs、中断、DMA、电源管理。每一类都有明确的改动原因和代码样例。接口类别3.x写法4.x写法改动原因字符设备注册register_chrdev(major, name, fops)register_chrdev_regioncdev_add4.x要求显式管理设备号范围避免主设备号冲突file_operations可以只填.ioctl需要unlocked_ioctl或compat_ioctl4.x默认不再持有大内核锁内核线程调用ioctl时也不会自动加锁proc创建create_proc_entryproc_create4.0后create_proc_entry被彻底移除sysfs属性DEVICE_ATTR直接使用DEVICE_ATTR_*系列宏或显式struct attribute4.x强化了属性组的生命周期管理tasklettasklet_inittasklet_setup或改用workqueue4.x里tasklet的回调参数从unsigned long改为struct tasklet_struct指针DMA一致性内存pci_alloc_consistentdma_alloc_coherentPCI API统一收敛为通用DMA API中断申请request_irq依然request_irq但需要检查IRQ域4.x对中断号合法性校验更严格非SPI/PCI中断请使用平台中断资源定时器init_timeradd_timertimer_setupadd_timer4.15移除data参数电源管理自定义suspend/resumedev_pm_ops和SET_SYSTEM_SLEEP_PM_OPS4.x弃用老的suspend、resume字段2.1 字符设备注册的完整示例Accel32驱动原先用register_chrdev注册了一个主设备号240次设备号用了0到7。这个方案在3.x上能用但到了4.x系统里已经有不少设备占用了240这个号。虽然register_chrdev不会直接失败但一旦和别的设备冲突/dev/accel32创建的节点访问到的可能是别的设备。我改成动态分配主设备号配合mdev或udev自动创建节点。static int accel32_setup_cdev(struct accel32_dev *dev) { int err; dev_t devno; err alloc_chrdev_region(devno, 0, ACCEL32_MINOR_COUNT, accel32); if (err) { pr_err(accel32: alloc_chrdev_region failed\n); return err; } dev-major MAJOR(devno); cdev_init(dev-cdev, accel32_fops); dev-cdev.owner THIS_MODULE; err cdev_add(dev-cdev, devno, ACCEL32_MINOR_COUNT); if (err) { pr_err(accel32: cdev_add failed\n); unregister_chrdev_region(devno, ACCEL32_MINOR_COUNT); return err; } return 0; }对应的user space侧用mknod /dev/accel32 c $(grep accel32 /proc/devices | awk {print $1}) 0创建节点。生产环境建议写成udev规则避免每次重启后手动处理。2.2 ioctl处理函数必须同时实现unlocked_ioctl和compat_ioctl64位内核上如果用户态进程是32位编译ioctl命令里的指针类型长度不同必须用compat_ioctl做转换。Accel32的设备库里有32位版本的采集控制程序用于和旧的32位工控软件兼容。4.x下如果只实现了unlocked_ioctl,32位用户态程序调用ioctl时返回-ENOTTY。我在accel32_fops里同时挂了两个回调static const struct file_operations accel32_fops { .owner THIS_MODULE, .open accel32_open, .release accel32_release, .unlocked_ioctl accel32_ioctl, .compat_ioctl accel32_compat_ioctl, .mmap accel32_mmap, .poll accel32_poll, };accel32_compat_ioctl针对已知的、包含指针参数的IOCTL命令做结构体尺寸转换其他命令直接透传给accel32_ioctl。这一步看起来简单但如果不做32位用户态程序在4.x上会表现出奇怪的命令无效或参数错误排查成本很高。2.3 proc节点和sysfs属性组Accel32驱动在/proc/accel32/status里导出了采集卡温度、FPGA版本号、DMA错误计数等信息。3.x时代用create_proc_entry创建目录和文件4.x上这个函数没了必须用proc_create。而且4.x对proc文件的读回调要求更严格read_proc必须返回实际读取字节数否则应用层读出来是空。我保留了/proc/accel32/status同时增加了一套/sys/class/accel32/下的属性组用于在用户态通过libsysfs或直接读文件获取设备状态。设备属性的写法static ssize_t fpga_version_show(struct device *dev, struct device_attribute *attr, char *buf) { struct accel32_dev *adev dev_get_drvdata(dev); return sprintf(buf, %u.%u\n, adev-fpga_major, adev-fpga_minor); } static DEVICE_ATTR_RO(fpga_version); static struct attribute *accel32_attrs[] { dev_attr_fpga_version.attr, dev_attr_dma_error_count.attr, NULL, }; static struct attribute_group accel32_attr_group { .attrs accel32_attrs, };在probe函数最后用sysfs_create_group(pdev-dev.kobj, accel32_attr_group)挂载。4.x下对attribute的生命周期管理更严格卸载驱动时一定要对应sysfs_remove_group否则会出现use-after-free。2.4 中断下半部和tasklet的坑Accel32用的是PCIe MSI中断中断处理函数里需要读取FPGA的状态寄存器判断中断源然后触发DMA传输。旧代码用tasklet处理下半部这个在4.19还能用但tasklet回调的参数变了// 3.x void accel32_tasklet_handler(unsigned long data); // 4.x void accel32_tasklet_handler(struct tasklet_struct *t);4.19内核里tasklet_init仍然存在但如果驱动的代码想同时兼容4.14和4.19需要在回调签名上做条件编译。我的做法是彻底弃用tasklet改用workqueue。原因有两点第一workqueue可以在进程上下文睡眠DMA缓冲区分配和等待队列唤醒都更方便第二4.x的tasklet在CPU热插拔和内核抢占模式下有优先级反转的风险中断密集场景下工作队列更可控。static irqreturn_t accel32_irq_handler(int irq, void *dev_id) { struct accel32_dev *dev dev_id; u32 status; status ioread32(dev-bar0 ACCEL32_IRQ_STATUS); if (!(status ACCEL32_IRQ_DMA_DONE)) return IRQ_NONE; iowrite32(status, dev-bar0 ACCEL32_IRQ_CLEAR); queue_work(dev-workqueue, dev-dma_work); return IRQ_HANDLED; }dma_work里执行完整的后处理更新环形缓冲区写指针、唤醒poll等待队列、如果有用户态缓冲就调用dma_sync_for_cpu。实测下来在4.19 x86_64上单次中断到工作队列回调执行的延迟比tasklet模式低了接近30%因为这个卡的中断频率不高大约50kHz不需要tasklet那种在中断上下文中紧贴执行的特性。2.5 DMA接口的迁移3.x时代Accel32驱动用pci_alloc_consistent分配DMA缓冲区。4.x内核虽然还保留了这个函数的兼容封装但推荐用法是dma_alloc_coherent。区别在于dma_alloc_coherent需要传入struct device *而不是struct pci_dev *。对PCIe设备来说用pdev-dev即可。dev-dma_buf dma_alloc_coherent(pdev-dev, ACCEL32_DMA_SIZE, dev-dma_addr, GFP_KERNEL);这看起来是机械替换但有一个隐蔽的坑旧代码没有设置dma_mask。3.x内核里某些PCI设备可以不设置掩码默认使用32位寻址但4.x上DMA API会检查dev-dma_mask如果不设置dma_alloc_coherent直接返回NULL或者在IOMMU开启时报错。必须在probe里补上dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));Accel32板卡的DMA引擎只支持48位地址所以实际设置成64位也安全因为FPGA侧如果有地址译码限制主机侧可以用IOMMU做映射。如果不想依赖IOMMU就设成DMA_BIT_MASK(48)同时DMA描述符里的地址字段必须用48位格式。我在做64位设置前专门查了FPGA手册确认它支持64位地址描述符才敢直接用。这一步务必核对硬件规格不要盲目照抄。3. 设备树和平台驱动Accel32在4.x下能正常枚举的前提Accel32是PCIe设备按理说PCI设备不依赖设备树PCI子系统自己就能完成枚举。但Accel32驱动里有个板级特性需要通过一个GPIO控制板卡复位信号而GPIO控制器挂在SoC的设备树下。这个在3.x时代靠arch/x86/platform下的自定义代码注册模拟GPIO芯片4.x后这种非标准做法基本行不通了。我把这部分拆成两个驱动一个标准的PCI驱动处理Accel32数据面一个极简的平台驱动导出这个复位GPIOPCI驱动通过gpiod_get获取。3.1 PCIe驱动注册与Bar资源Accel32的PCI vendor ID是0x10EEXilinxdevice ID是0x9038自定义。老驱动在pci_driver里只填了id_table和probe函数4.x对resource申请检查更严格——如果probe里不调用pci_request_mem_regions直接ioremap虽然能映射成功但会和内核的resource管理冲突在后续的/proc/iomem中看不到占用可能导致其他驱动误用。正确流程static int accel32_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) { struct accel32_dev *dev; int err; err pcim_enable_device(pdev); if (err) return err; err pci_request_mem_regions(pdev, accel32); if (err) return err; dev devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev-pdev pdev; dev-bar0 pcim_iomap(pdev, 0, pci_resource_len(pdev, 0)); pci_set_master(pdev); pci_set_drvdata(pdev, dev); // ... }这里推荐用pcim_enable_device和devm_*系列这样驱动卸载时资源自动释放避免手动清理遗漏。4.x内核里devm_设备资源管理框架已经非常成熟老驱动里大段的goto err释放代码可以删掉大半。3.2 MSI中断申请与irq affinityAccel32支持MSI-X有4个中断向量分别用于DMA完成、采集错误、温度告警和命令完成。在4.x里申请MSI-X的方式和3.x差不多但有一个微妙的变化pci_enable_msix要求传入的struct msix_entry数组的entry字段是硬件偏移量而4.x对偏移量有效性的校验更严格。如果硬件不支持某个偏移量直接返回-EINVAL不会像3.x那样自动降级。我使用的配置static int accel32_setup_msix(struct accel32_dev *dev) { struct msix_entry entries[4] { {.entry 0,}, {.entry 1,}, {.entry 2,}, {.entry 3,}, }; int err; err pci_enable_msix_range(dev-pdev, entries, 4, 4); if (err 0) { dev_err(dev-pdev-dev, MSI-X setup failed: %d\n, err); return err; } dev-irq_dma_done entries[0].vector; // ... }这里单独说一下irq affinity。4.x里如果希望某个中断向量固定在某个CPU上可以用irq_set_affinity_hint。Accel32的DMA完成中断我固定到CPU2采集错误中断固定到CPU3这样中断处理不彼此干扰配合RPSReceive Packet Steering之外的用户态轮询整体采集延迟更稳定。3.3 复位GPIO的平台驱动由于Accel32在x86嵌入式主板上使用GPIO控制器来自主板上的IT8728F超级IO芯片。3.x时代我直接用gpio_request加固定IO端口号操作4.x下这不安全而且主板的GPIO编号可能变化。改为在设备树或者ACPI看平台里声明accel32_reset_gpio: accel32-reset { compatible accel32,gpio-reset; reset-gpio gpio0 13 GPIO_ACTIVE_HIGH; };平台驱动里用devm_gpiod_get_optional获取GPIO描述符PCI驱动probe的时候通过pci_platform_notify或者模块间导出函数获取。这里如果不方便改设备树也可以用gpiod_get_index配合ACPI的_DSD属性。最大好处是GPIO编号由内核统一管理用户态通过/sys/class/gpio查看时不会被别的驱动误占用。4. 用户态数据通路重建Accel32性能稳定的关键驱动编过、设备能枚举只是第一步。真正影响采集效果的是数据通路。Accel32数据采集的核心逻辑是FPGA不断往DMA缓冲区写数据驱动在中断里更新写指针用户态通过mmap直接读到数据或者用read()零拷贝拷贝到用户缓冲区。4.1 mmap 环形缓冲区的实现旧驱动把一整块DMA缓冲区映射到用户态用户态程序通过查询尾部指针来判断新数据。4.x下这个模式可以继续用但要注意4.x的remap_pfn_range相比3.x对页框号合法性检查更严格不能再随便拿一个物理地址加偏移就当pfn用。static int accel32_mmap(struct file *filp, struct vm_area_struct *vma) { struct accel32_dev *dev filp-private_data; unsigned long size vma-vm_end - vma-vm_start; if (size ACCEL32_DMA_SIZE) return -EINVAL; vma-vm_flags | VM_DONTEXPAND | VM_DONTDUMP; vma-vm_ops accel32_vm_ops; return remap_pfn_range(vma, vma-vm_start, virt_to_phys(dev-dma_buf) PAGE_SHIFT, size, vma-vm_page_prot); }一个容易忽略的细节vma-vm_flags要为映射区域设置VM_DONTEXPAND防止用户态通过mremap意外扩展映射范围否则可能映射到DMA缓冲区之外的内核地址。4.2 poll/waitqueue 的时序细节用户态采集进程会通过poll等待新数据到达。驱动的poll回调要把等待队列挂到poll_wait上static unsigned int accel32_poll(struct file *filp, struct poll_table_struct *wait) { struct accel32_dev *dev filp-private_data; unsigned int mask 0; poll_wait(filp, dev-data_wait, wait); if (accel32_data_ready(dev)) mask | POLLIN | POLLRDNORM; return mask; }这里有一个非常隐蔽的时序问题FPGA DMA完成中断触发queue_work工作队列回调里设置数据就绪标志并wake_up_interruptible(dev-data_wait)。如果用户态正好在poll系统调用里排队等待那么唤醒正常。但如果用户态循环先检查了accel32_data_ready再进入poll之间存在竞态窗口驱动可能先在中断里设置标志和唤醒然后用户态才调用poll如果poll没有把线程放到等待队列上就会漏掉唤醒。解决办法是典型的检查-再等待顺序问题正确做法是先poll_wait挂入等待队列再检查数据就绪标志。poll_wait本身把当前线程关联到等待队列上即使检查之后数据才到达唤醒机制也能保证不会丢事件。4.3 通过一个内部泄漏问题看4.x的缓存一致性要求Accel32板卡使用DMA写数据到主存驱动在中断处理里必须做一次缓存同步。3.x里我用dma_sync_single_for_cpu4.x里接口变成dma_sync_single_for_cpu或dma_sync_for_cpu但要注意dma_alloc_coherent分配的内存本身是uncached或write-combine的不需要每次同步。只有dma_map_single映射的流式DMA缓冲区才需要。我在调试过程中遇到过一次现象数据采集几个小时以后用户态读到的数据偶尔会有几百字节的跳变像是DMA错过了几个采样点。后来用perf和bpftrace排查发现是FPGA在cache line大小边界上跨了两个page导致DMA描述符的地址没有按cache line对齐。解决办法是把DMA缓冲区大小调整为page size的整数倍并在驱动初始化时强制把缓冲区起始地址对齐到dma_get_cache_alignment()。这里提一下FPGA侧如果支持scatter-gather那么把DMA描述符按page散开更灵活但如果FPGA只支持连续地址就必须保证连续物理内存足够。4.4 用户态测试程序原型的调整我用一个简单的用户态程序验证采集通路核心就是初始化设备、分配环形缓冲、设置采集参数、进入采集循环# 设备初始化 ./accel32_util --init --rate 100000 --channels 32 # 启动采集 ./accel32_util --start --duration 60 --output /data/record.bin用户态程序必须处理EINTR。4.x的poll在接收信号时返回-EINTR如果采集程序把这个当成fatal error退出就会在长时间运行时莫名中断。正确的处理是判断errno EINTR后重试poll。5. 多版本内核兼容从4.4到4.19的心得Accel32要跑在不同客户的内核环境上。有的客户还在用Ubuntu 16.04的4.4内核有的已经用了Debian 10的4.19内核。驱动代码因此需要一套版本兼容宏保证一个源码包能编出多个版本都正常的模块。5.1 版本兼容宏的写法在头文件里定义统一的封装#include linux/version.h #if LINUX_VERSION_CODE KERNEL_VERSION(4, 15, 0) #define ACCEL32_TIMER_SETUP(timer, cb) timer_setup(timer, cb, 0) #else #define ACCEL32_TIMER_SETUP(timer, cb) init_timer(timer); timer-function cb #endif同理4.4和4.19的proc_create参数数量其实不同——4.4就已经是4参数版本3.x是3参数所以只需要区分3.x和4.x。另外4.4的poll回调没有poll_flags参数4.16引入了poll_state但接口签名没变所以不用处理。我把所有需要兼容的内核API列了一个表每个接口后面记录最低支持版本和最高支持版本避免以后升级到5.x时再踩一遍。接口最低版本最高版本备注timer_setup4.155.x老内核用init_timerproc_create3.105.x3.x用create_proc_entrypci_enable_msix_range3.145.x老版本用pci_enable_msixdma_set_mask_and_coherent3.135.x老版本分别设置两个掩码devm_gpiod_get_optional4.25.x老版本用gpio_request_one5.2 实测4.4、4.9、4.14、4.19四个内核的稳定性数据我在同一台工控机上分别安装了4.4、4.9、4.14、4.19四个内核用同一个驱动源码编译四份模块然后连续跑48小时采集内核版本编译通过采集48小时数据丢包率DMA错误计数平均中断延迟(us)4.4是0.0002%018.54.9是0.0001%016.24.14是0.0001%011.84.19是0.0000%09.6说明4.4上的中断延迟波动较大因为4.4对PCIe MSI的irq affinity支持不如4.14之后完善中断可能在不同CPU间漂移。4.14之后引入了更细粒度的irq管理延迟明显下降。这里有一个额外收获4.19内核默认开启了CONFIG_HARDENED_USERCOPY它会检查copy_to_user的源头是否属于合法内核对象。Accel32驱动在用户态读取环形缓冲时用copy_to_user返回值来判断拷贝是否成功在4.19下多了一层性能损失约2%但安全性提升明显。我没有为了性能关闭这个选项而是调整了用户态读取策略用mmap直读替代copy_to_user既安全又更快。6. 踩过的其他坑和调试工具推荐除了上面这些接口迁移和设计调整还有几个零散但很影响体验的坑值得单独列出来。6.1 内核模块签名机制从4.4开始内核如果开启了CONFIG_MODULE_SIG_FORCE所有外部编译的.ko文件必须签名才能加载。Ubuntu默认没有强制但某些安全加固过的发行版会强制。Accel32驱动如果要在这类系统上加载需要把模块编译进内核树或者在构建后用sign-file工具签上对应内核的证书。最简单的绕开方式是把模块放到内核树外编译然后借助DKMS在安装时自动重新编译DKMS会匹配当前内核的配置避免签名问题。但如果目标系统强制签名还是得老老实实注册证书。6.2 用devmem和busybox在最早阶段排查FPGA寄存器驱动调试时我习惯先用devmem直接读取PCIe BAR上的寄存器确认FPGA已经正确枚举并且寄存器映射正常。比如# 查看PCI设备BAR地址 lspci -v -s 03:00.0 # 直接读取FPGA ID寄存器 devmem 0xdf900000 32如果devmem读出来的值和FPGA手册里的默认值不一致先别怀疑驱动先查PCIe链路是否协商到了正确的速率和宽度——用lspci -vv看LnkSta。Accel32运行在PCIe Gen2 x4下如果主板只协商到Gen1 x1带宽会差很多倍采集速率上限直接下降。这个问题在3.x时代不容易暴露因为驱动没有严格检查带宽4.x下中断频率高一些就明显丢数据。6.3 内核日志的过滤驱动的pr_err和dev_err在4.x里默认会打满整个内核环形缓冲调试时容易把关键信息淹没。可以用dmesg -n 3限制日志级别或者给驱动加一个动态调试开关通过dynamic_debug控制echo module accel32 p /sys/kernel/debug/dynamic_debug/control这个在4.x里非常方便。我在驱动里把所有调试打印都从pr_debug输出发布版本里不会刷屏调试时打开开关就能看到完整流程。6.4 用户态查看DMA计数器最后Accel32用户态工具里加了一个小功能实时打印DMA错误计数。在采集状态下这个数字应该是0如果持续增长优先怀疑PCIe链路质量或者中断丢失。watch -n1 cat /sys/class/accel32/dma_error_count一旦某个时刻这个数字变成非0后面的采集数据就不能要了必须重启采集线程。这类错误在3.x下也出现过但4.4以后有更完善的PCIe AER错误上报配合rasdaemon能定位到更底层的链路问题。结尾Accel32在Linux 4.xx内核上的适配过程说到底是老设备与新内核接口的一场持久战。对我个人来说最有价值的不仅是把驱动改到编译通过而是借着这次迁移把驱动里所有依赖旧API的地方全部清理了一遍定时器换了、ioctl做兼容了、DMA对齐了、MSI中断重新设计了。这一轮改完驱动在4.4到4.19之间跑得很稳也为将来迁移5.x打好了基础。最后分享一个小技巧这类驱动适配工作开工前先把/lib/modules/$(uname -r)/build/include/linux/下相关的头文件用diff工具和旧内核对比一遍哪些接口变了、哪些函数没了一目了然。不用急着改代码先把接口差异清单列出来改起来会顺畅很多。内核接口的演进方向都是朝着更清晰、更安全去的老驱动跟上这个节奏未来的维护成本反而更低。
Accel32驱动从Linux 3.x到4.x的迁移实践与接口适配
这段时间一直在折腾Accel32在Linux 4.xx内核下的适配工作。Accel32是一张PCIe接口的32通道数据采集加速卡板载FPGA做信号预处理通过DMA和主机交换数据。之前它的驱动一直是基于3.x内核写的构建脚本、接口调用、设备注册方式全是老一套放到4.x内核上编译直接一片报错。这篇就把整个适配过程中遇到的坑、接口迁移明细、以及最后稳定运行的方法完整梳理一遍给同样在做内核适配的同行一个参考。先交代一下使用场景我这边主要用Accel32做工业现场的多通道信号采集比如振动分析、电网波形记录这类对同步性和吞吐量要求比较高的场合。主机平台是x86_64的工控机内核从3.16升级到4.19。LTS版本的内核维护周期长驱动适配一次能管很久所以这次迁移的目标就是4.19当然代码里也做了4.4、4.9、4.14的兼容处理。整个过程下来最大的体会是4.xx内核的改动虽然不像2.6到3.0那次伤筋动骨但API层面的删除力度很坚决老驱动如果不主动跟上基本就是编不过、装不上、跑不起来的命运。下面按我实际操作时的顺序来写从最开始的编译报错到设备枚举、数据通路重建再到多版本兼容和稳定性验证。1. 老驱动在4.xx内核上第一次编译失败五个最直接的硬伤Accel32的旧驱动写于2014年前后当时内核版本还是3.13。直接放到4.19上执行make报错信息将近两百行而且很多错误是一处引发几十个后续连环报错。我处理这类问题有个习惯不从头扫错先抓第一个真实的编译错误修掉再继续编译。重复几轮后真正阻碍编译通过的硬伤大概有五个。1.1 构建脚本里的内核版本判断完全失效旧Makefile里用了这样的判断逻辑ifeq ($(shell test $(KERNELRELEASE) -ge 3.10 echo yes), yes) EXTRA_CFLAGS -DHAVE_NEW_MMAP endif这里的KERNELRELEASE在4.19下是4.19.0-xxx-generic带一串后缀字符串比较根本不是数字比较的结果。测试得到的结果永远是假导致新代码路径全被屏蔽老代码路径又编不过。正确的做法是解析出数字版本号再比较KERNEL_MAJOR : $(shell uname -r | cut -d. -f1) KERNEL_MINOR : $(shell uname -r | cut -d. -f2)这里还需要注意驱动编译必须依赖目标内核的构建目录如果为多个内核版本构建不要使用当前正在运行的uname -r而应该通过KDIR传入目标内核源码路径再从KDIR下的include/config/kernel.release文件读取版本号。例如KDIR ? /lib/modules/$(shell uname -r)/build KREL : $(shell cat $(KDIR)/include/config/kernel.release) KMAJ : $(shell echo $(KREL) | cut -d. -f1) KMIN : $(shell echo $(KREL) | cut -d. -f2)这种取法在主线内核和发行版内核上都能用。写死字符串比较是很多老驱动常见的问题排查时值得第一个看。1.2 驱动入口处的printk级别宏被移动旧代码里用了类似#include linux/version.h然后通过#if LINUX_VERSION_CODE KERNEL_VERSION(3,10,0)来走不同分支。这个思路本身没问题但4.19下很多头文件的包含路径相比3.x调整过。比如UTS_RELEASE这类的定义在4.x里依赖linux/utsname.h或者generated/utsrelease.h。单纯依赖linux/version.h可能会导致编译时找不到某些宏。更常见的报错是关于console_printk或者CONSOLE_LOGLEVEL_DEFAULT。3.x时代可以直接extern引用这些符号4.0以后内核把printk的实现做了整理直接引用会报undefined symbol或者在编译时就提示隐式声明。Accel32驱动里打印环形缓冲状态用到了这一类接口我干脆全部换成pr_info、pr_err和dev_info不再直接操作内核日志级别。1.3 老式挂载方式的file_operations结构体不再被接受4.x内核里字符设备的file_operations成员函数虽然名字没变但内核内部对.owner THIS_MODULE的要求更严格了而且如果驱动用了.ioctl字段编译时会出现-Werrormissing-field-initializers之类的警告在某些内核配置下直接变成错误。另外一个问题是3.x时代很多驱动用.aio_read、.aio_write这类异步接口4.0以后这些接口被移除统一走.read_iter和.write_iter。Accel32旧驱动没走异步IO但我在检查时发现用户态的工具链里有用到libaio的例程这些例程在内核4.x下依然能用因为底层是io_submit加read_iter。如果驱动本身不实现read_iter那么所有pread调用都会走默认的default_file_splice_read路径性能损失明显这一点后面再展开。1.4 timer接口的替换是4.15之后绕不过去的坎Accel32驱动里有两个地方用到了内核定时器一个是看门狗定时一个是DMA超时重试。老写法是init_timer(dev-watchdog_timer); dev-watchdog_timer.function accel32_watchdog_callback; dev-watchdog_timer.data (unsigned long)dev; add_timer(dev-watchdog_timer);4.15内核引入了timer_setup接口同时把data参数去掉由from_timer宏从struct timer_list反推包含它的结构体。新写法是timer_setup(dev-watchdog_timer, accel32_watchdog_callback, 0);回调函数签名也从void (*)(unsigned long)变成了void (*)(struct timer_list *)void accel32_watchdog_callback(struct timer_list *t) { struct accel32_dev *dev from_timer(dev, t, watchdog_timer); // 原逻辑照搬 }这个改动不是单纯改名from_timer宏里用了container_of所以回调里拿到的指针一定是包含timer_list的那个结构体首地址比老式的data指针更安全。我顺便排查了驱动里所有init_timer用法确保没有遗漏。4.19下如果还用init_timer编译直接报错没有过渡期。1.5 并发控制相关API的名称调整3.x时代常用lock_kernel()、unlock_kernel()的驱动在4.x里直接定义都找不到。Accel32驱动没用这些全局锁但它用了semaphore作为用户态IO的互斥量而include/linux/semaphore.h在4.x里的依赖变了。单独引入这个头文件没问题但如果驱动里同时用up()和down_interruptible()4.19下会把down_interruptible标记为已废弃虽然还能编过但会产生警告。我统一改成了mutex_lock_interruptible配合mutex类型。这个改动同样需要仔细检查所有等待唤醒路径避免mutex和waitqueue混用时出现死锁。经过这几轮修补驱动终于能编译成.ko文件了。但是insmod时候立刻遇到第二个问题注册失败提示No such device。这说明编译层面的问题解决了设备枚举层面的问题还没解决。2. 从3.x到4.xAccel32需要迁移的驱动接口明细这节把Accel32驱动里所有做过迁移的内核接口列一个对照表方便其他做老设备适配的人直接对着查。我把这些接口分成五个维度字符设备、proc/sysfs、中断、DMA、电源管理。每一类都有明确的改动原因和代码样例。接口类别3.x写法4.x写法改动原因字符设备注册register_chrdev(major, name, fops)register_chrdev_regioncdev_add4.x要求显式管理设备号范围避免主设备号冲突file_operations可以只填.ioctl需要unlocked_ioctl或compat_ioctl4.x默认不再持有大内核锁内核线程调用ioctl时也不会自动加锁proc创建create_proc_entryproc_create4.0后create_proc_entry被彻底移除sysfs属性DEVICE_ATTR直接使用DEVICE_ATTR_*系列宏或显式struct attribute4.x强化了属性组的生命周期管理tasklettasklet_inittasklet_setup或改用workqueue4.x里tasklet的回调参数从unsigned long改为struct tasklet_struct指针DMA一致性内存pci_alloc_consistentdma_alloc_coherentPCI API统一收敛为通用DMA API中断申请request_irq依然request_irq但需要检查IRQ域4.x对中断号合法性校验更严格非SPI/PCI中断请使用平台中断资源定时器init_timeradd_timertimer_setupadd_timer4.15移除data参数电源管理自定义suspend/resumedev_pm_ops和SET_SYSTEM_SLEEP_PM_OPS4.x弃用老的suspend、resume字段2.1 字符设备注册的完整示例Accel32驱动原先用register_chrdev注册了一个主设备号240次设备号用了0到7。这个方案在3.x上能用但到了4.x系统里已经有不少设备占用了240这个号。虽然register_chrdev不会直接失败但一旦和别的设备冲突/dev/accel32创建的节点访问到的可能是别的设备。我改成动态分配主设备号配合mdev或udev自动创建节点。static int accel32_setup_cdev(struct accel32_dev *dev) { int err; dev_t devno; err alloc_chrdev_region(devno, 0, ACCEL32_MINOR_COUNT, accel32); if (err) { pr_err(accel32: alloc_chrdev_region failed\n); return err; } dev-major MAJOR(devno); cdev_init(dev-cdev, accel32_fops); dev-cdev.owner THIS_MODULE; err cdev_add(dev-cdev, devno, ACCEL32_MINOR_COUNT); if (err) { pr_err(accel32: cdev_add failed\n); unregister_chrdev_region(devno, ACCEL32_MINOR_COUNT); return err; } return 0; }对应的user space侧用mknod /dev/accel32 c $(grep accel32 /proc/devices | awk {print $1}) 0创建节点。生产环境建议写成udev规则避免每次重启后手动处理。2.2 ioctl处理函数必须同时实现unlocked_ioctl和compat_ioctl64位内核上如果用户态进程是32位编译ioctl命令里的指针类型长度不同必须用compat_ioctl做转换。Accel32的设备库里有32位版本的采集控制程序用于和旧的32位工控软件兼容。4.x下如果只实现了unlocked_ioctl,32位用户态程序调用ioctl时返回-ENOTTY。我在accel32_fops里同时挂了两个回调static const struct file_operations accel32_fops { .owner THIS_MODULE, .open accel32_open, .release accel32_release, .unlocked_ioctl accel32_ioctl, .compat_ioctl accel32_compat_ioctl, .mmap accel32_mmap, .poll accel32_poll, };accel32_compat_ioctl针对已知的、包含指针参数的IOCTL命令做结构体尺寸转换其他命令直接透传给accel32_ioctl。这一步看起来简单但如果不做32位用户态程序在4.x上会表现出奇怪的命令无效或参数错误排查成本很高。2.3 proc节点和sysfs属性组Accel32驱动在/proc/accel32/status里导出了采集卡温度、FPGA版本号、DMA错误计数等信息。3.x时代用create_proc_entry创建目录和文件4.x上这个函数没了必须用proc_create。而且4.x对proc文件的读回调要求更严格read_proc必须返回实际读取字节数否则应用层读出来是空。我保留了/proc/accel32/status同时增加了一套/sys/class/accel32/下的属性组用于在用户态通过libsysfs或直接读文件获取设备状态。设备属性的写法static ssize_t fpga_version_show(struct device *dev, struct device_attribute *attr, char *buf) { struct accel32_dev *adev dev_get_drvdata(dev); return sprintf(buf, %u.%u\n, adev-fpga_major, adev-fpga_minor); } static DEVICE_ATTR_RO(fpga_version); static struct attribute *accel32_attrs[] { dev_attr_fpga_version.attr, dev_attr_dma_error_count.attr, NULL, }; static struct attribute_group accel32_attr_group { .attrs accel32_attrs, };在probe函数最后用sysfs_create_group(pdev-dev.kobj, accel32_attr_group)挂载。4.x下对attribute的生命周期管理更严格卸载驱动时一定要对应sysfs_remove_group否则会出现use-after-free。2.4 中断下半部和tasklet的坑Accel32用的是PCIe MSI中断中断处理函数里需要读取FPGA的状态寄存器判断中断源然后触发DMA传输。旧代码用tasklet处理下半部这个在4.19还能用但tasklet回调的参数变了// 3.x void accel32_tasklet_handler(unsigned long data); // 4.x void accel32_tasklet_handler(struct tasklet_struct *t);4.19内核里tasklet_init仍然存在但如果驱动的代码想同时兼容4.14和4.19需要在回调签名上做条件编译。我的做法是彻底弃用tasklet改用workqueue。原因有两点第一workqueue可以在进程上下文睡眠DMA缓冲区分配和等待队列唤醒都更方便第二4.x的tasklet在CPU热插拔和内核抢占模式下有优先级反转的风险中断密集场景下工作队列更可控。static irqreturn_t accel32_irq_handler(int irq, void *dev_id) { struct accel32_dev *dev dev_id; u32 status; status ioread32(dev-bar0 ACCEL32_IRQ_STATUS); if (!(status ACCEL32_IRQ_DMA_DONE)) return IRQ_NONE; iowrite32(status, dev-bar0 ACCEL32_IRQ_CLEAR); queue_work(dev-workqueue, dev-dma_work); return IRQ_HANDLED; }dma_work里执行完整的后处理更新环形缓冲区写指针、唤醒poll等待队列、如果有用户态缓冲就调用dma_sync_for_cpu。实测下来在4.19 x86_64上单次中断到工作队列回调执行的延迟比tasklet模式低了接近30%因为这个卡的中断频率不高大约50kHz不需要tasklet那种在中断上下文中紧贴执行的特性。2.5 DMA接口的迁移3.x时代Accel32驱动用pci_alloc_consistent分配DMA缓冲区。4.x内核虽然还保留了这个函数的兼容封装但推荐用法是dma_alloc_coherent。区别在于dma_alloc_coherent需要传入struct device *而不是struct pci_dev *。对PCIe设备来说用pdev-dev即可。dev-dma_buf dma_alloc_coherent(pdev-dev, ACCEL32_DMA_SIZE, dev-dma_addr, GFP_KERNEL);这看起来是机械替换但有一个隐蔽的坑旧代码没有设置dma_mask。3.x内核里某些PCI设备可以不设置掩码默认使用32位寻址但4.x上DMA API会检查dev-dma_mask如果不设置dma_alloc_coherent直接返回NULL或者在IOMMU开启时报错。必须在probe里补上dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));Accel32板卡的DMA引擎只支持48位地址所以实际设置成64位也安全因为FPGA侧如果有地址译码限制主机侧可以用IOMMU做映射。如果不想依赖IOMMU就设成DMA_BIT_MASK(48)同时DMA描述符里的地址字段必须用48位格式。我在做64位设置前专门查了FPGA手册确认它支持64位地址描述符才敢直接用。这一步务必核对硬件规格不要盲目照抄。3. 设备树和平台驱动Accel32在4.x下能正常枚举的前提Accel32是PCIe设备按理说PCI设备不依赖设备树PCI子系统自己就能完成枚举。但Accel32驱动里有个板级特性需要通过一个GPIO控制板卡复位信号而GPIO控制器挂在SoC的设备树下。这个在3.x时代靠arch/x86/platform下的自定义代码注册模拟GPIO芯片4.x后这种非标准做法基本行不通了。我把这部分拆成两个驱动一个标准的PCI驱动处理Accel32数据面一个极简的平台驱动导出这个复位GPIOPCI驱动通过gpiod_get获取。3.1 PCIe驱动注册与Bar资源Accel32的PCI vendor ID是0x10EEXilinxdevice ID是0x9038自定义。老驱动在pci_driver里只填了id_table和probe函数4.x对resource申请检查更严格——如果probe里不调用pci_request_mem_regions直接ioremap虽然能映射成功但会和内核的resource管理冲突在后续的/proc/iomem中看不到占用可能导致其他驱动误用。正确流程static int accel32_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) { struct accel32_dev *dev; int err; err pcim_enable_device(pdev); if (err) return err; err pci_request_mem_regions(pdev, accel32); if (err) return err; dev devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev-pdev pdev; dev-bar0 pcim_iomap(pdev, 0, pci_resource_len(pdev, 0)); pci_set_master(pdev); pci_set_drvdata(pdev, dev); // ... }这里推荐用pcim_enable_device和devm_*系列这样驱动卸载时资源自动释放避免手动清理遗漏。4.x内核里devm_设备资源管理框架已经非常成熟老驱动里大段的goto err释放代码可以删掉大半。3.2 MSI中断申请与irq affinityAccel32支持MSI-X有4个中断向量分别用于DMA完成、采集错误、温度告警和命令完成。在4.x里申请MSI-X的方式和3.x差不多但有一个微妙的变化pci_enable_msix要求传入的struct msix_entry数组的entry字段是硬件偏移量而4.x对偏移量有效性的校验更严格。如果硬件不支持某个偏移量直接返回-EINVAL不会像3.x那样自动降级。我使用的配置static int accel32_setup_msix(struct accel32_dev *dev) { struct msix_entry entries[4] { {.entry 0,}, {.entry 1,}, {.entry 2,}, {.entry 3,}, }; int err; err pci_enable_msix_range(dev-pdev, entries, 4, 4); if (err 0) { dev_err(dev-pdev-dev, MSI-X setup failed: %d\n, err); return err; } dev-irq_dma_done entries[0].vector; // ... }这里单独说一下irq affinity。4.x里如果希望某个中断向量固定在某个CPU上可以用irq_set_affinity_hint。Accel32的DMA完成中断我固定到CPU2采集错误中断固定到CPU3这样中断处理不彼此干扰配合RPSReceive Packet Steering之外的用户态轮询整体采集延迟更稳定。3.3 复位GPIO的平台驱动由于Accel32在x86嵌入式主板上使用GPIO控制器来自主板上的IT8728F超级IO芯片。3.x时代我直接用gpio_request加固定IO端口号操作4.x下这不安全而且主板的GPIO编号可能变化。改为在设备树或者ACPI看平台里声明accel32_reset_gpio: accel32-reset { compatible accel32,gpio-reset; reset-gpio gpio0 13 GPIO_ACTIVE_HIGH; };平台驱动里用devm_gpiod_get_optional获取GPIO描述符PCI驱动probe的时候通过pci_platform_notify或者模块间导出函数获取。这里如果不方便改设备树也可以用gpiod_get_index配合ACPI的_DSD属性。最大好处是GPIO编号由内核统一管理用户态通过/sys/class/gpio查看时不会被别的驱动误占用。4. 用户态数据通路重建Accel32性能稳定的关键驱动编过、设备能枚举只是第一步。真正影响采集效果的是数据通路。Accel32数据采集的核心逻辑是FPGA不断往DMA缓冲区写数据驱动在中断里更新写指针用户态通过mmap直接读到数据或者用read()零拷贝拷贝到用户缓冲区。4.1 mmap 环形缓冲区的实现旧驱动把一整块DMA缓冲区映射到用户态用户态程序通过查询尾部指针来判断新数据。4.x下这个模式可以继续用但要注意4.x的remap_pfn_range相比3.x对页框号合法性检查更严格不能再随便拿一个物理地址加偏移就当pfn用。static int accel32_mmap(struct file *filp, struct vm_area_struct *vma) { struct accel32_dev *dev filp-private_data; unsigned long size vma-vm_end - vma-vm_start; if (size ACCEL32_DMA_SIZE) return -EINVAL; vma-vm_flags | VM_DONTEXPAND | VM_DONTDUMP; vma-vm_ops accel32_vm_ops; return remap_pfn_range(vma, vma-vm_start, virt_to_phys(dev-dma_buf) PAGE_SHIFT, size, vma-vm_page_prot); }一个容易忽略的细节vma-vm_flags要为映射区域设置VM_DONTEXPAND防止用户态通过mremap意外扩展映射范围否则可能映射到DMA缓冲区之外的内核地址。4.2 poll/waitqueue 的时序细节用户态采集进程会通过poll等待新数据到达。驱动的poll回调要把等待队列挂到poll_wait上static unsigned int accel32_poll(struct file *filp, struct poll_table_struct *wait) { struct accel32_dev *dev filp-private_data; unsigned int mask 0; poll_wait(filp, dev-data_wait, wait); if (accel32_data_ready(dev)) mask | POLLIN | POLLRDNORM; return mask; }这里有一个非常隐蔽的时序问题FPGA DMA完成中断触发queue_work工作队列回调里设置数据就绪标志并wake_up_interruptible(dev-data_wait)。如果用户态正好在poll系统调用里排队等待那么唤醒正常。但如果用户态循环先检查了accel32_data_ready再进入poll之间存在竞态窗口驱动可能先在中断里设置标志和唤醒然后用户态才调用poll如果poll没有把线程放到等待队列上就会漏掉唤醒。解决办法是典型的检查-再等待顺序问题正确做法是先poll_wait挂入等待队列再检查数据就绪标志。poll_wait本身把当前线程关联到等待队列上即使检查之后数据才到达唤醒机制也能保证不会丢事件。4.3 通过一个内部泄漏问题看4.x的缓存一致性要求Accel32板卡使用DMA写数据到主存驱动在中断处理里必须做一次缓存同步。3.x里我用dma_sync_single_for_cpu4.x里接口变成dma_sync_single_for_cpu或dma_sync_for_cpu但要注意dma_alloc_coherent分配的内存本身是uncached或write-combine的不需要每次同步。只有dma_map_single映射的流式DMA缓冲区才需要。我在调试过程中遇到过一次现象数据采集几个小时以后用户态读到的数据偶尔会有几百字节的跳变像是DMA错过了几个采样点。后来用perf和bpftrace排查发现是FPGA在cache line大小边界上跨了两个page导致DMA描述符的地址没有按cache line对齐。解决办法是把DMA缓冲区大小调整为page size的整数倍并在驱动初始化时强制把缓冲区起始地址对齐到dma_get_cache_alignment()。这里提一下FPGA侧如果支持scatter-gather那么把DMA描述符按page散开更灵活但如果FPGA只支持连续地址就必须保证连续物理内存足够。4.4 用户态测试程序原型的调整我用一个简单的用户态程序验证采集通路核心就是初始化设备、分配环形缓冲、设置采集参数、进入采集循环# 设备初始化 ./accel32_util --init --rate 100000 --channels 32 # 启动采集 ./accel32_util --start --duration 60 --output /data/record.bin用户态程序必须处理EINTR。4.x的poll在接收信号时返回-EINTR如果采集程序把这个当成fatal error退出就会在长时间运行时莫名中断。正确的处理是判断errno EINTR后重试poll。5. 多版本内核兼容从4.4到4.19的心得Accel32要跑在不同客户的内核环境上。有的客户还在用Ubuntu 16.04的4.4内核有的已经用了Debian 10的4.19内核。驱动代码因此需要一套版本兼容宏保证一个源码包能编出多个版本都正常的模块。5.1 版本兼容宏的写法在头文件里定义统一的封装#include linux/version.h #if LINUX_VERSION_CODE KERNEL_VERSION(4, 15, 0) #define ACCEL32_TIMER_SETUP(timer, cb) timer_setup(timer, cb, 0) #else #define ACCEL32_TIMER_SETUP(timer, cb) init_timer(timer); timer-function cb #endif同理4.4和4.19的proc_create参数数量其实不同——4.4就已经是4参数版本3.x是3参数所以只需要区分3.x和4.x。另外4.4的poll回调没有poll_flags参数4.16引入了poll_state但接口签名没变所以不用处理。我把所有需要兼容的内核API列了一个表每个接口后面记录最低支持版本和最高支持版本避免以后升级到5.x时再踩一遍。接口最低版本最高版本备注timer_setup4.155.x老内核用init_timerproc_create3.105.x3.x用create_proc_entrypci_enable_msix_range3.145.x老版本用pci_enable_msixdma_set_mask_and_coherent3.135.x老版本分别设置两个掩码devm_gpiod_get_optional4.25.x老版本用gpio_request_one5.2 实测4.4、4.9、4.14、4.19四个内核的稳定性数据我在同一台工控机上分别安装了4.4、4.9、4.14、4.19四个内核用同一个驱动源码编译四份模块然后连续跑48小时采集内核版本编译通过采集48小时数据丢包率DMA错误计数平均中断延迟(us)4.4是0.0002%018.54.9是0.0001%016.24.14是0.0001%011.84.19是0.0000%09.6说明4.4上的中断延迟波动较大因为4.4对PCIe MSI的irq affinity支持不如4.14之后完善中断可能在不同CPU间漂移。4.14之后引入了更细粒度的irq管理延迟明显下降。这里有一个额外收获4.19内核默认开启了CONFIG_HARDENED_USERCOPY它会检查copy_to_user的源头是否属于合法内核对象。Accel32驱动在用户态读取环形缓冲时用copy_to_user返回值来判断拷贝是否成功在4.19下多了一层性能损失约2%但安全性提升明显。我没有为了性能关闭这个选项而是调整了用户态读取策略用mmap直读替代copy_to_user既安全又更快。6. 踩过的其他坑和调试工具推荐除了上面这些接口迁移和设计调整还有几个零散但很影响体验的坑值得单独列出来。6.1 内核模块签名机制从4.4开始内核如果开启了CONFIG_MODULE_SIG_FORCE所有外部编译的.ko文件必须签名才能加载。Ubuntu默认没有强制但某些安全加固过的发行版会强制。Accel32驱动如果要在这类系统上加载需要把模块编译进内核树或者在构建后用sign-file工具签上对应内核的证书。最简单的绕开方式是把模块放到内核树外编译然后借助DKMS在安装时自动重新编译DKMS会匹配当前内核的配置避免签名问题。但如果目标系统强制签名还是得老老实实注册证书。6.2 用devmem和busybox在最早阶段排查FPGA寄存器驱动调试时我习惯先用devmem直接读取PCIe BAR上的寄存器确认FPGA已经正确枚举并且寄存器映射正常。比如# 查看PCI设备BAR地址 lspci -v -s 03:00.0 # 直接读取FPGA ID寄存器 devmem 0xdf900000 32如果devmem读出来的值和FPGA手册里的默认值不一致先别怀疑驱动先查PCIe链路是否协商到了正确的速率和宽度——用lspci -vv看LnkSta。Accel32运行在PCIe Gen2 x4下如果主板只协商到Gen1 x1带宽会差很多倍采集速率上限直接下降。这个问题在3.x时代不容易暴露因为驱动没有严格检查带宽4.x下中断频率高一些就明显丢数据。6.3 内核日志的过滤驱动的pr_err和dev_err在4.x里默认会打满整个内核环形缓冲调试时容易把关键信息淹没。可以用dmesg -n 3限制日志级别或者给驱动加一个动态调试开关通过dynamic_debug控制echo module accel32 p /sys/kernel/debug/dynamic_debug/control这个在4.x里非常方便。我在驱动里把所有调试打印都从pr_debug输出发布版本里不会刷屏调试时打开开关就能看到完整流程。6.4 用户态查看DMA计数器最后Accel32用户态工具里加了一个小功能实时打印DMA错误计数。在采集状态下这个数字应该是0如果持续增长优先怀疑PCIe链路质量或者中断丢失。watch -n1 cat /sys/class/accel32/dma_error_count一旦某个时刻这个数字变成非0后面的采集数据就不能要了必须重启采集线程。这类错误在3.x下也出现过但4.4以后有更完善的PCIe AER错误上报配合rasdaemon能定位到更底层的链路问题。结尾Accel32在Linux 4.xx内核上的适配过程说到底是老设备与新内核接口的一场持久战。对我个人来说最有价值的不仅是把驱动改到编译通过而是借着这次迁移把驱动里所有依赖旧API的地方全部清理了一遍定时器换了、ioctl做兼容了、DMA对齐了、MSI中断重新设计了。这一轮改完驱动在4.4到4.19之间跑得很稳也为将来迁移5.x打好了基础。最后分享一个小技巧这类驱动适配工作开工前先把/lib/modules/$(uname -r)/build/include/linux/下相关的头文件用diff工具和旧内核对比一遍哪些接口变了、哪些函数没了一目了然。不用急着改代码先把接口差异清单列出来改起来会顺畅很多。内核接口的演进方向都是朝着更清晰、更安全去的老驱动跟上这个节奏未来的维护成本反而更低。