1. 驱动到底在干什么很多做应用开发的朋友第一次接触设备驱动时容易陷入一个误区觉得驱动就是“操作寄存器”、“读写端口”的那几百行汇编或者认为驱动是搞硬件的人才会碰的东西。真正入行之后你会慢慢发现设备驱动更像一个“翻译官”和“管家”——它夹在硬件和应用层之间负责把硬件那一堆电平信号、寄存器状态翻译成应用层能理解的接口同时把应用层的指令解析成硬件能执行的时序操作。我遇到过不少类似的情况项目进度紧迫硬件那边板子已经点亮了应用层要开始调功能结果发现设备节点还没影儿。这时候你才发现驱动程序要完成的功能远不止“点灯”这么简单。从内核模块加载、设备号申请、文件操作接口注册到中断处理、数据缓冲、并发控制再到用户态和内核态之间的数据搬运方案每一步都踩过坑、填过雷。这篇文章不是教科书式地复述概念而是结合我自己做过的几类典型外设驱动GPIO按键、串口、DMA采集这类常见场景把“驱动要完成的功能”和“数据传送方案”这两条主线彻底拆开。核心会围绕几个问题展开驱动在系统里到底处在什么位置、它必须向内核和外层提供哪些能力、数据从硬件到应用层有哪些传送路径、不同路径各自适合什么场景、以及实际调板时哪些地方最容易让人怀疑人生。适合正在学驱动的同学、刚接触嵌入式Linux开发的新手还有从MCU裸机开发转向Linux带系统开发的这帮朋友——你们会发现很多裸机时代想当然的东西放到有操作系统、有MMU、有进程调度的环境里完全变成了另一套玩法。2. 设备驱动需要向内核交付哪些核心能力2.1 设备识别与实例化驱动要完成的第一件事是让内核知道“我负责的是什么东西”。听起来简单做起来有不少细节。以Linux字符设备为例一个驱动模块在加载时至少要做这么几件事分配并注册设备号、初始化设备相关的数据结构、把这个设备挂到内核的设备模型上。设备号这里容易踩第一个坑。主设备号标识设备类型次设备号标识同类型下的不同实例。手动指定主设备号虽然省事但很容易和系统里已有的驱动冲突特别是你做的项目要发布、要适配不同内核版本时冲突概率不小。自己写驱动优先用动态分配dev_t dev_num; alloc_chrdev_region(dev_num, 0, 1, demo_dev); major_num MAJOR(dev_num);动态分配的好处显而易见——内核帮你挑一个没被占用的主设备号不需要你去翻内核源码查哪个号还没人用。配合mknod创建设备节点时也方便做成脚本自动获取。设备实例化这一层在Linux 2.6之后有了更规范的玩法也就是设备模型。cdev、device、class这三件套很多人一开始搞不清楚区别。我是这么理解的cdev是字符设备在内核里的“登记表”告诉VFS层我这个驱动提供了哪些文件操作device是它硬件层面的“身份标签”用来和设备树或总线匹配class则是用来在用户空间自动生成设备节点时做分类管理。三者搭配配合udev设备插上就能自动出现/dev下的节点省去了手动mknod的麻烦。2.2 文件操作接口的完整实现驱动向应用层暴露能力靠的是file_operations结构体。这个结构体就是驱动提供给VFS层的“菜单”。很多人第一次写驱动以为实现open、read、write、release就够了。实际跑起来你会发现当你的设备被多个进程同时打开、当用户用select或epoll监控你的设备、当应用层需要配置某些非数据传输的参数时你还需要实现很多“隐藏菜单”。比如.llseek如果你不实现默认行为可能导致偏移量被错误计算连续读两次数据就会出问题。再比如.poll这是实现非阻塞IO和事件通知的关键串口驱动、GPIO中断驱动的标准配置。.unlocked_ioctl则是处理设备控制的“万能接口”——设置波特率、调整采样频率、开启某项硬件特性都可以通过它下发命令。这里有一个特别容易犯迷糊的点read和write这两个接口职责边界到底在哪里。以我做过的一个模拟项目X为例某传感器设备需要先下发一条配置命令再读取测量结果。如果只是简单地把配置数据写进write把结果从read里拿出来理论上没毛病。但实际做的时候会发现应用层可能在同一时刻对设备做了并发读写而你的驱动如果没有设计好锁和缓冲数据就会串。所以文件操作接口不只是一个函数指针表它背后涉及的是并发模型、数据一致性、阻塞与非阻塞模式这套完整的体系。2.3 中断处理与事件上报机制设备驱动里最考验人的部分大概率是中断。裸机时代写中断服务函数关全局中断、处理、再开中断流程清晰。到了Linux内核中断处理被拆成了上半部和下半部而且你的中断服务函数里不能调用可能睡眠的函数。为什么这么设计直接原因是为了保证系统响应性能。中断处理期间如果CPU被一个耗时操作占住更紧急的中断就无法得到响应。把不紧急的工作推迟到下半部中断上下文就能以极短的时间完成关键操作然后迅速返回。内核提供的中断下半部机制有三种比较常用软中断、tasklet、工作队列。实践中我建议优先考虑tasklet或workqueue除非你有非常明确的理由去碰软中断。tasklet的特点是执行在软中断上下文不能睡眠工作队列则运行在进程上下文可以睡眠也因此可以用来执行那些需要等待的操作比如唤醒等待队列上的进程。中断处理另一头连着事件上报。设备发生的事件怎么通知应用层两种主流方案一是通过等待队列配合阻塞IO应用层阻塞在read上中断来了唤醒它二是通过poll机制让应用层用select/epoll去等待可读事件。第二种方案在目前的主流架构里用得更广因为它天然适配高并发和事件驱动模型——应用层用一个线程监测一堆设备节点哪个有事处理哪个不用为每个设备开一个阻塞线程。2.4 并发控制与资源保护驱动开发做到一定深度并发控制是绕不开的一道坎。要时刻记住你的驱动代码运行在内核态可能同时被多个上下文执行——进程上下文、中断上下文、多核CPU上的并行执行。如果没有合适的保护机制数据竞争、指针悬空、设备寄存器状态错乱各种诡异问题接踵而来。Linux内核提供的并发控制手段包括自旋锁、互斥体mutex、读写锁、原子变量、RCU等。选它们的核心依据是你保护的是临界区的代码执行时间还是数据访问的一致性。短临界区用自旋锁虽然忙等浪费CPU但避免了睡眠带来的调度开销和上下文切换长临界区用互斥体可以让出CPU但要注意不能在中断上下文使用互斥体。实际开发中我见过不少人一上来就锁满天飞生怕哪里没锁出问题。结果性能测试时发现吞吐量惨不忍睹锁竞争成了瓶颈。正确思路是先梳理清楚共享资源的访问路径——哪些数据会被哪些上下文访问、访问频次如何——再决定锁的粒度。能用原子变量解决的不要用锁锁的范围能缩到几条语句的不要扩大到整个函数。驱动程序的并发设计本质上是在“正确性”和“性能”之间做取舍。3. 数据传送方案从硬件寄存器到应用层缓冲区的完整链路3.1 I/O端口与I/O内存数据搬运的起点数据传送的第一步是CPU和外设寄存器之间的交互。x86体系里有独立的I/O地址空间访问需要专用的指令ARM等嵌入式体系则是内存映射IO外设寄存器被映射到内存地址空间直接通过指针读写就行。Linux内核里这两类访问被抽象成了统一的接口。对于I/O内存核心操作是request_mem_region声明资源占用、ioremap完成物理地址到内核虚拟地址的映射。很多刚接触的同学在这里会疑问ioremap到底映射的是什么它是把外设寄存器的物理地址映射到内核地址空间的高端区域之后你操作这个虚拟地址硬件上对应的就是操作那片寄存器区域。需要注意一个大坑外设寄存器的访问不能用普通的C语言指针操作直接读写。原因在于编译器的优化行为和CPU的缓存机制——寄存器读写很多是有副作用的读操作可能会清中断标志写操作可能会触发硬件动作一旦被编译器优化掉或者被缓存延迟写入硬件的状态就全错了。内核提供了readl/writel等一系列访问接口确保每次访问都直接落在物理设备上不做缓存。这一点裸机开发者转型过来时最需要适应。3.2 轮询、中断与DMA的取舍逻辑数据从外设到内存传统上无非三种途径轮询读取、中断通知读取、DMA直接搬运。三者没有绝对的好坏完全看场景。轮询最简单CPU不断检查设备状态寄存器看数据是否就绪。好处是逻辑简单、无上下文切换开销坏处是忙等CPU在等待期间不能干别的事。适用于数据量小、速率慢、且CPU没什么其他任务可做的场景。比如GPIO按键消抖检测轮询完全够用。中断方式解决了CPU白白等待的问题设备有数据时主动通知CPUCPU暂停当前任务去处理。这里注意中断处理只是“通知”真正的数据拷贝通常还是CPU来做的。适用于中低速设备比如串口、网卡的传统收发模式。中断方式的问题是频繁的中断会导致CPU上下文切换开销变得很大——如果设备每秒产生10万次中断CPU大部分时间都在来回切换反而效率下降。DMA的方案彻底解决了这个问题。DMA控制器在外设和内存之间直接搬运数据搬运过程不需要CPU参与。CPU只需要在传输开始前设置好源地址、目的地址、传输长度传输完成后由DMA控制器发中断通知CPU“搞定了”。这适用于高速设备、大批量数据传输的场景比如块设备、音频采集、高速数据采集卡。三种方案放在一个表里更好懂方式CPU开销实时性适用场景轮询高全程占用高随时响应低速、简单外设中断中仅通知时介入中有调度延迟中低速、事件型外设DMA低搬运不参与由中断通知决定高速、大批量数据3.3 内核态到用户态的四条数据通路数据到了内核缓冲区之后接下来的问题是怎么把它交到应用层手里。这是驱动开发中最常被问到的部分也是“数据传送方案”的精华所在。结合我做过的项目常用的有四条路径各有各的使用场景和坑。第一条也是最传统的copy_to_user与copy_from_user。内核缓冲区里的数据通过这两个函数拷贝到用户空间缓冲区。关键点在于内核态不能直接解引用用户空间的指针。原因很简单——用户空间指针指向的页面可能不在内存中被换出了直接访问会触发缺页异常而且恶意应用可能传入非法地址内核直接访问会引发内核崩溃。copy_to_user内部会处理这些情况并在拷贝失败时返回未拷贝的字节数。这个返回值一定要检查否则应用层拿到的数据不完整你还不知道问题出在哪。第二条mmap内存映射。如果数据量很大每次都用copy_to_user拷贝开销会非常大。mmap的做法是把内核缓冲区映射到应用层地址空间应用层直接读写这段内存就像操作普通数组一样。零拷贝、延迟极低非常适合帧数据、采样数据这类大块数据的高频传输场景。但代价是缓冲区管理变复杂了环形缓冲区的读写指针需要在驱动和应用层之间协调好还要处理缓存一致性问题。第三条ioctl命令通道。它主要不是搬运大量数据而是传输控制信息和少量配置参数。结构体指针通过ioctl下发驱动内部解析后配置硬件。这套机制灵活、易扩展设备控制类的需求基本靠它解决。但要注意不要把大量数据放到ioctl里做搬运否则既不符合内核的设计习惯性能上也划不来。第四条netlink与其它高级机制。这类一般用于驱动需要主动向用户态推送事件而不只是被读的情况。比如网络设备的状态变化、热插拔事件、硬件报警。netlink提供了一种内核态主动发消息给用户态进程的能力配合socket接口实现异步事件通知。注意这是“主动通知”和之前的“被动读取”在编程模型上有本质区别。3.4 环形缓冲区与DMA协同时的缓存一致性现在把场景拉高高速设备用DMA搬运数据不断写入驱动管理的缓冲区应用层同时从缓冲区读取。这里最经典的工程方案是DMA环形缓冲区。DMA控制器反复在缓冲区里写新数据应用程序在另一头读走旧数据读写的节奏由各自的指针来标示不需要每次传输都停一下。但这里藏着两个工程上很容易踩爆的雷。第一个雷是DMA缓存一致性问题。DMA控制器读写的是物理内存而CPU侧有Cache。问题来了DMA写内存后Cache里可能还是旧数据或者CPU改了Cache里的数据DMA去读内存读到的还是旧的。这种情况下必须在合适的位置做Cache的同步操作。内核提供了一套DMA API来应对核心是正确使用dma_alloc_coherent分配一致性DMA缓冲区或使用dma_map_single配合流式映射的管理方式。前者适合长期存在的缓冲区简单省事后者适合一次性传输灵活但需要小心处理的时机。我在实际项目中遇到过这样的情况DMA采集回来的数据第一次读正常后面数据全乱。排查大半天发现是分配缓冲区时没有使用DMA一致性APICPU读到的是Cache里的残影。这类问题用工具还很难查因为它不是逻辑错误而是底层存储架构导致的脏数据问题。所以这里我的建议是涉及DMA的缓冲区一定要用正确API分配不要抱着“我用kmalloc也凑合”的心态。凑合的代价是现场调试时怀疑人生。第二个雷是环形缓冲区的读写指针同步。驱动中你在中断上下文更新读指针应用层在用户态同时更新它的读偏移这两者之间是通过共享内存通信的中间没有任何锁机制全靠原子操作和内存屏障保证可见性。所以必须用READ_ONCE/WRITE_ONCE这类宏来访问共享指针确保编译器不会对它们做重排序优化、不会缓存它们到寄存器里。这个细节要是忽略了极难复现的偶发性数据错乱就会找上你。4. 实操从一个GPIO按键驱动看功能如何落地4.1 需求拆解与功能规划光说概念比较虚拿一个具体的例子走一遍流程。某跨平台系统需要一个GPIO按键驱动硬件上按钮接在某个GPIO引脚上按下为低电平。需求列出来是这样的应用层能读取按键当前状态按键按下和释放时应用层能及时收到事件支持防抖避免机械抖动产生多次事件驱动能配置按键是否启用或通过系统休眠策略控制把需求翻译成驱动功能点对应的是这些设备树中声明GPIO引脚及中断触发方式实现file_operations中的open、read、poll、release在中断上半部做标记工作队列做按键状态读取和防抖处理用等待队列配合poll实现事件的通知和阻塞读以上就是一个很典型的“功能拆解”过程。不少人拿到需求直接开写代码写到一半发现这里缺个结构、那里缺个函数。先把功能点清晰地列出来后面每一项都能找到对应的实现载体整条线就顺了。4.2 中断、防抖与事件上报的代码走读下面是这个驱动里最核心的一段逻辑我简化了一些错误处理重点看主路径static irqreturn_t key_int_handler(int irq, void *dev_id) { struct key_dev *dev dev_id; // 上半部只做标记 schedule_work(dev-work); return IRQ_HANDLED; } static void key_work_handler(struct work_struct *work) { struct key_dev *dev container_of(work, struct key_dev, work); int val gpiod_get_value(dev-desc); u64 now ktime_get_ms(); // 简单的防抖实现与上一次事件间隔小于30ms的忽略 if (now - dev-last_press_time 30) { dev-last_press_time now; return; } dev-last_press_time now; // 更新共享状态、唤醒等待队列 spin_lock(dev-lock); dev-key_state val; spin_unlock(dev-lock); wake_up_interruptible(dev-wq); }上半部设置为不可睡眠所以中断处理函数里去读取GPIO、申请锁、打印日志之类耗时的事都不要做只做最紧要的标记。把真正的处理放到工作队列这是Linux驱动的标准范式。防抖这里其实是一道送分题但也很容易翻车。机械按键在按下和释放的瞬间由于触点物理弹跳会产生多次电平跳变。如果在中断边缘触发模式下不加处理一次按下会触发多个中断。上面的实现用时间过滤来做简单消抖——两次事件间隔小于30ms认为是抖动。经验值上说大部分机械按键在10~20毫秒后趋于稳定30ms是一个稳妥的阈值既不会丢掉快速连按也能有效过滤大多数抖动。事件上报这层wake_up_interruptible是核心。当按键事件发生时驱动唤醒在等待队列上睡眠的读进程。配合poll接口应用层就能用select/epoll等方式异步等待事件。4.3 poll接口在这里起到的作用很多人对poll接口的作用理解不到位以为是不是select/epoll的底层就是轮询查状态。其实poll接口的正确含义是驱动告诉内核“我这个设备的某些事件是否已经就绪”。它是一种“立即回答”的机制而不是周期查询。实现poll接口时有三件事要做调用poll_wait把这个设备的等待队列加入到内核的poll_table中检查事件是否就绪如果有数据可读就返回POLLIN | POLLRDNORM否则返回0。代码如下static unsigned int key_poll(struct file *filp, poll_table *wait) { struct key_dev *dev filp-private_data; unsigned int mask 0; poll_wait(filp, dev-wq, wait); if (/* 条件有可读事件 */ 1) { mask | POLLIN | POLLRDNORM; } return mask; }也就是说当应用层调用select/epoll等待时内核最终会调用到这个poll接口看看事件是否就绪。如果没就绪应用层进入睡眠直到驱动在中断到来时调用wake_up_interruptible把等待中的进程唤醒。唤醒后内核会再次调用poll接口确认事件状态从而完成事件从硬件到应用层的完整传递。这一套机制理解透了以后写任何“有事件时通知我”类型的驱动比如串口收到数据、网卡收到包、传感器产生新读数都用得上。5. 数据传送方案选型对比与适用场景5.1 大块数据与小包控制的方案选型表做驱动时一个逃不掉的问题是“我该用哪种数据传送方式”我的建议是不要背选型表而是先回答清楚四个问题数据量多大、实时性要求多高、是主动推送还是被动读取、CPU预算还剩多少。回答完这四个问题方案基本就浮出水面了。这里我整理一个常用的选型参考表场景描述推荐方案原因小数据量低频例如按键状态字符设备read/write 轮询/中断简单直接满足需求大数据量高频例如视频帧、ADC采样mmap零拷贝 环形缓冲区减少拷贝开销吞吐量高控制类操作如设置参数、启动/停止ioctl语义清晰扩展方便内核主动推送的异步事件如热插拔、告警netlink或poll 事件队列支持主动通知适合事件驱动模型中速连续数据流如串口收发字符设备 中断 read/write实现成熟生态兼容性好这表只能作为参考不能教条化。比如某场景虽然是小数据量但应用层对延迟要求极端严格那可能还需要考虑中断线程化或者更高优先级的工作队列来优化调度延迟而不是简单套用字符设备那套阻塞读的逻辑。5.2 从应用层视角看阻塞、非阻塞与异步通知站在应用层看驱动另一种分法是你希望你的read调用是阻塞等数据还是立刻拿到结果还是让系统主动通知你“有数据了”。阻塞模式最简单应用层调用read时没有数据就睡在那有数据了才返回。驱动侧用等待队列实现。这种模式下每个应用线程处理一个设备代码好写但线程资源开销大。非阻塞模式要求驱动在数据未就绪时立即返回返回错误码-EAGAIN应用层自己决定接下来怎么办。这种方式驱动侧实现简单但应用层代码写起来绕——你得配合忙轮询或延迟重试很少单独使用通常会配合select/poll来等事件。异步通知用的是SIGIO信号。应用层通过fcntl配置把设备文件描述符设为异步通知模式驱动在有事件时向进程发送SIGIO信号。这种方式代码量少、响应比较及时但信号机制在复杂应用里不太好管理实际项目里用select/epoll的更多。三种方式我建议理解透底层机制后再选择。阻塞是基础非阻塞是补充异步是特殊场景。掌握这几种模型的转化条件——关键的还是驱动里那套等待队列和poll机制——以后再遇到“应用层和驱动怎么交互”这类问题心里就有底了。5.3 DMA在高速数据采集中怎么设计凡是标了“高速采集”的项目基本逃不开DMA。以某图像处理Demo为例传感器输出1280x720分辨率的图像帧30fps每个像素两个字节。算一下每秒的数据量大概是1280×720×2×30约55MB/s。如果这个量级的数据每次都要CPU从中断中断点拷贝一次CPU的占用率直接拉满别的任务基本没法做了。这种情况只能用DMA。DMA设计上有几个关键参数要在初始化时和硬件手册对好数据传输方向外设到内存、内存到外设还是双向、传输粒度字节、字、突发长度、描述符的数量和排列。这些参数错了轻则数据错乱重则总线错误直接死机。另一个参数是DMA缓冲区的尺寸。缓冲区太小DMA频繁触发“满了”的中断吞吐量上不去缓冲区太大内存占用和延迟都会上升。实际经验是从“一个采集周期数据量的4倍”这个基准开始调然后配合性能测试逐步微调。DMA传输结束还有一件容易被忽视的事中断服务函数里要判断是哪个通道的事件、传输是否真的完成了。DMA控制器通常用一个状态寄存器记录当前传输状态。不检查就贸然认为“传输完成”一旦出现总线错误或描述符配置错误你拿到的数据可能是不完整的而程序还在自我感觉良好地运行。6. 常见问题与排查技巧6.1 数据从驱动到应用层总是慢半拍这个问题我见到过很多次功能是对的就是用起来感觉不灵敏应用层要过一阵子才能收到数据。排查思路一般是这么走的先区分是驱动上报慢还是应用层处理慢。最直接的手段是看中断频率。在中断处理函数里放一个计数器cat /proc/interrupts观察计数是否跟着设备事件同步增长。如果中断增长正常但应用层响应不及时那问题大概率出在驱动中从中断到唤醒用户的链路。重点查一下下半部机制是否因为被更高优先级任务抢占延误了执行或者等待队列唤醒是否因为在锁竞争上消耗太久。如果中断本身频率就异常那回到硬件配置上去查触发电平、中断共享这些基础项。我还见过一种特殊情况驱动里用了schedule_work来跑下半部但系统负载较高时工作队列的调度延迟会明显拉长。换成tasklet或者直接把工作放在中断线程化处理里响应会更快但可睡眠的行为就没了。这是一个典型的“决策权衡”案例——实时性要求高到什么程度就得牺牲多少实现上的便利。6.2 为什么我的mmap缓冲区数据时而新时而旧这个问题本质是缓存一致性问题的外在表现。用mmap共享内核缓冲区时应用层直接读的是CPU映射的虚拟地址而数据写入者可能是DMA控制器或者CPU本身。如果两边不是同一个视角一个访问Cache一个访问物理内存最后看到的可能是不一致的视图。解决方案有两种思路。一种是用dma_alloc_coherent分配共享缓冲区这类缓冲区在硬件设计上就是“非缓存”的读写都会直接穿透Cache到达内存一致性天然保证。另一种是用dma_map_single做流式映射传输前做dma_map_single使Cache失效传输后做dma_unmap_single再使Cache失效保证CPU不会读到DMA写入前的残影。从工程角度我推荐能用一致性缓冲区就优先用一致性缓冲区省心很多。流式映射虽然灵活但管理Cache的时机一旦出错偶发性数据错乱足够你排查一整天。6.3 驱动加载正常但设备节点无法操作很多时候驱动insmod成功/proc/devices里也能看到主设备号但应用层打开/dev下的节点时总是提示无法找到设备或者权限不足。这类问题十有八九出在设备节点创建这个环节。如果设备节点是手动mknod创建的先核对主设备号、次设备号跟驱动注册的一致不一致。另一个高频原因是没有正确使用class设备模型。驱动里调用了class_create和device_createudev才会在设备出现的瞬间自动生成节点。如果驱动里没有做这一步节点得完全手动管理一旦系统重启或者设备重新加载节点可能就找不到设备了。还有一个细节设备节点的权限。不是所有应用进程都有权限直接操作设备节点而很多驱动程序开发者自己测试时会用root用户切换到普通应用进程时权限问题就浮现出来了。6.4 排查工具与方法心得最后整理一份驱动调试的常用工具和方法都是我自己实际用下来觉得靠得住的dmesg是驱动日志的大本营开发阶段建议在关键路径上多打印但要注意生产版本的打印要收敛否则日志刷屏会影响IO性能。/proc/interrupts用来确认中断是否正常触发还能看到中断在各CPU上的分布情况有时能帮你发现中断集中某个核导致的性能问题。/proc/devices查看主设备号的分配情况。trace系列工具基于内核的追踪框架在排查调度延迟和中断延迟时非常有用。此外strace能从应用层跟踪open、read、write等系统调用的返回值对排查应用层使用方法问题很有帮助。调试内核驱动心态上要做好“慢就是快”的准备。出问题时先不要急着猜先复现再打日志缩小范围。我见过太多人在代码里乱加打印结果问题变成“加了打印就正常、去了打印就复现”那种情况最让人头疼。好的做法是隔离问题源头用最小的代码路径复现再一点一点加点东西看什么时候触发变化。这种方法虽然慢但定位问题最精准。7. 关于驱动开发的几点心得一路踩坑走过来有个体会挺深的驱动开发不是“会写寄存器操作”就完了它更像是在操作系统和硬件两个世界之间搭桥。你要懂一点体系结构因为缓存一致性、MMU映射这些底层机制直接决定数据的正确性你也要懂一点操作系统的任务调度、进程管理因为驱动的阻塞、唤醒、并发控制都是建立在操作系统内核的机制之上的你还要具备组件设计思维——一个功能可以从哪些接口透出、事件通过哪种方式通知应用层这些都是在动手写代码之前就要想清楚的。从学习路径来说我建议初学的朋友不要一头扎进源码海洋里试图通读内核。先做几个小实验写一个只有open和release的驱动跑通模块加载和设备节点的创建再扩展一个read接口用copy_to_user返回一个固定的数据再做一个用等待队列配合poll的按键驱动。把这三步走完驱动的主要脉络就已经在脑子里立起来了。后续再碰到复杂的场景无非是给这条路加上DMA、加锁、加中断优化这些强化组件而已。最后分享一个小技巧跑系统的时候多留意一下/sys和/proc下与你的设备相关的条目。它们不只是调试的“窗口”也是检验你的驱动是否真正嵌入到内核设备模型中的一个标准。如果你的设备出现在sysfs里说明device模型这一层做对了如果与设备相关的属性都能在sysfs里看到说明你的驱动在功能完整性上已经上了一层台阶。开发驱动本身不难难的是养成一种从操作系统全局角度审视自己代码的习惯。有了这个习惯后面的路会越走越顺。
