看到《手把手教你学Linux设备驱动开发》正式出版的消息我第一时间就入手了。老实说现在市面上讲Linux驱动开发的资料并不少但要么是几百页的宏篇巨著让人翻两章就放弃要么是网上零散的帖子看的时候觉得懂了、合上电脑依然写不出一个像样的驱动程序。所以对这本号称“硬核宝典”的新书我的期待很高也确实想看看它能不能把驱动开发这个公认难啃的硬骨头讲明白。Linux设备驱动开发从来都不是一个“看会”的领域。它是Linux内核和硬件之间的桥梁层既要懂C语言和操作系统原理又要理解CPU体系结构、中断、内存映射、总线协议这些偏底层的知识还要能在内核崩溃、系统死机的情况下通过有限的日志把问题定位出来。这套组合拳劝退了很多人。尤其是做嵌入式Linux开发的朋友面试时被问设备树、platform驱动、中断下半部、DMA一致性缓存这些概念时有没有一种“平时好像见过但要系统讲出来又说不清”的感觉如果你有这种感觉这篇文章就是为你准备的。这篇文章我会结合新书出版这件事深入拆解Linux设备驱动开发的核心主线、学习路径、调试手段和常见大坑也会把我实际开发中积累的一些经验放进来。不管是刚入门的学生、转行做嵌入式的工程师还是已经在写驱动但想补系统知识的开发者都值得耐心看完。1. 驱动开发这个门槛为什么卡住了大部分人1.1 市场需求很大劝退率也很高嵌入式Linux和驱动开发在招聘市场上的热度从来没有降过。从智联、BOSS直聘到各个技术社群的招聘帖Linux驱动工程师、BSP工程师、内核工程师的薪资普遍高于普通应用开发。为什么因为供给少。Linux内核源码几千万行设备驱动占据了70%以上但这个领域的学习曲线实在太陡了。很多人一上来就试图通读Linux内核源码结果在include/linux头文件里迷路还有人直接拿一块开发板开始“照着教程敲命令”结果连modprobe加载模块失败的原因都搞不清楚。问题不在学习态度而在缺少一条能把内核机制、硬件特性和代码实操串起来的路径。这也是我一直认为“有人带着走一遍 自己动手写一遍”才是驱动开发唯一高效学习方式的原因。1.2 三个最常见的认知误区结合我带过的新人和社群里高频出现的问题我总结出三个最容易劝退初学者的认知误区误区一写驱动必须精通内核源码。实际上驱动开发有自己的一套范式——字符设备驱动、platform驱动、设备树匹配、中断注册、ioctl实现这些都有固定的套路和模板。你不需要通读内核只需要理解内核提供的API机制掌握数据在用户态和内核态之间如何流转即可。内核源码最大的作用是当字典查而不是当小说读。误区二调试驱动一定要有开发板。很多人在学习阶段就被“没有硬件”卡住。其实x86主机上的Linux完全可以用于学习模块编写和字符设备驱动配合QEMU模拟的ARM开发板可以覆盖设备树、platform驱动、中断等大部分嵌入式场景。等到需要调I2C、SPI、DMA这些外设时再上真实硬件效率会高很多。误区三内核崩溃Oops/Panic很难定位。实际上内核崩溃留下的日志包含了非常丰富的信息异常地址、调用栈、寄存器状态、模块加载地址等。学会读Oops日志是驱动开发的基本功而且这个能力是完全可以通过刻意练习获得的。后面我会专门讲这块。1.3 官方资料虽全但对新手并不友好Linux内核官方文档、LDD3Linux Device Drivers, 3rd Edition都是公认的经典资料但它们的定位是参考资料而非学习教程。Documentation目录下的文档更新很快但很多只讲API用法不讲设计思路和适用场景LDD3出版于2005年基于2.6内核放到今天很多API已经变了新读者照着敲根本编译不过。这也是我认为《手把手教你学Linux设备驱动开发》这类书存在的真正价值它解决的不是“有没有资料”的问题而是“有没有一条既符合当前内核版本、又有清晰学习路径、还能跟着动手做”的指引问题。新书如果能在这一点上做好价值就是实打实的。2. 从出版消息看这本书的内容框架和定位2.1 面向实战的内容组织方式从目前放出的信息看这本书不是一本单纯的内核源码分析也不是一个“命令速查手册”而是按照“环境准备 → 基础驱动 → 机制深入 → 综合实战”的逻辑来组织内容的。这是我认为驱动开发最合理的学习顺序。第一阶段的重点是搭建开发环境、理解内核模块的基本结构、掌握insmod/rmmod/modprobe等模块管理工具以及Makefile和Kconfig的编写。别小看这一步很多人在模块编译阶段就被kernel版本不一致、缺少头文件、符号未导出这类问题卡住其实就是环境没搞对。第二阶段通常会进入字符设备驱动这是理解文件操作接口file_operations和用户态交互的最佳入口。通过实现open、read、write、ioctl等接口可以建立起“系统调用最终如何到达设备驱动”的完整链路认知。第三阶段会涉及平台设备驱动和设备树。这部分是与真实硬件结合最紧密的内容也是从“能编译模块”进阶到“能编BSP”的分水岭。2.2 覆盖的知识点是否踩在了关键主线上从内容介绍来看这本书覆盖了几个驱动开发绝对绕不开的核心主题字符设备驱动与file_operations接口实现platform总线、设备驱动模型与设备树匹配机制中断处理、软中断、tasklet、工作队列并发控制自旋锁、信号量、互斥锁内核内存分配、mmap、DMA与一致性缓存常见外设驱动GPIO、I2C、SPI、UART内核调试手段printk、ftrace、kprobe、Oops分析这个覆盖范围是符合当前嵌入式Linux开发实际需求的。特别是设备树和platform驱动模型这是现代内核驱动开发的核心骨架很多老教程里要么没有、要么讲得太浅。如果这本书真的能做到“手把手”级别把这些知识从原理到代码一步步讲透那它就有资格被称为“硬核宝典”。2.3 和其他同类书籍相比的差异化市面上的驱动开发书不少但大多数要么源码解析过深、忽略了读者“不知道要解决什么问题”的困境要么例程太少、无法覆盖完整外设类型。这本书从标题看更强调“手把手”意味着它有大量的可执行例程、逐行代码解释和实验步骤这种风格对学习者更友好。当然任何一本书都不能替代你自己的实践和思考。我通常的建议是选一本主线清晰的书作为骨架再配合源码阅读和一个具体的项目目标才能真正把驱动开发学扎实。这本书如果能把主线串清楚就是一个非常好的学习骨架。3. 学驱动的核心突破口是理解设备驱动模型3.1 device、driver、bus三者到底什么关系很多初学者写驱动程序时一头扎进module_init、probe这些宏和函数里却不理解内核为什么要引入这套机制。其实只要理解了bus → device → driver这个三角关系整个驱动模型的骨架就清晰了。在Linux设备模型中struct bus_type代表一种总线类型如platform_bus_type、i2c_bus_type、spi_bus_type。总线负责连接设备和驱动每当注册一个新的device或driver时总线都会触发一次匹配过程把相同名字或兼容ID的设备和驱动绑定在一起。匹配成功后驱动中的probe函数被调用驱动开始初始化硬件并注册相应的子系统接口。用生活化的比喻来说device相当于一个灯泡driver相当于一个灯泡说明书而bus则是那个负责“把说明书和灯泡配到一起”的人。只有配对成功灯泡才能被正确点亮。static const struct of_device_id my_led_of_match[] { { .compatible vendor,my-led }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, my_led_of_match); static struct platform_driver my_led_driver { .probe my_led_probe, .remove my_led_remove, .driver { .name my_led, .of_match_table my_led_of_match, }, }; module_platform_driver(my_led_driver);理解这个三角关系后你会发现写一个驱动本质上就是做四件事定义驱动结构体、实现probe/remove回调、通过宏注册到总线、在设备树或代码中声明设备信息。套路化程度非常高。3.2 probe函数为什么是所有驱动的核心入口probe函数是驱动和硬件真正建立联系的起点。在这个函数里你要完成设备资源的获取platform_get_resource、寄存器映射ioremap或devm_ioremap_resource、中断申请request_irq或devm_request_irq、子系统注册如misc_register、i2c_add_driver等工作。现代内核大量采用devm_前缀的托管接口managed device resource这些接口的好处是当设备注销时内核会自动释放对应的资源不需要你在remove函数里手动释放。这个设计极大减少了驱动中资源泄漏的风险。写新驱动时建议优先使用devm_系列API。static int my_led_probe(struct platform_device *pdev) { struct resource *res; void __iomem *base; res platform_get_resource(pdev, IORESOURCE_MEM, 0); base devm_ioremap_resource(pdev-dev, res); if (IS_ERR(base)) return PTR_ERR(base); dev_info(pdev-dev, my_led probed successfully\n); return 0; }probe函数还有一个容易被忽略的点它运行在进程上下文可以睡眠调用msleep、wait_event等所以可以在里面做相对耗时的初始化操作。但如果你的驱动处理的是中断相关的初始化要特别注意注册时机和并发问题。3.3 设备树匹配机制是必须读懂的关键设备树Device Tree是描述硬件设备信息的一种数据结构它让内核从“代码里硬编码板级信息”转向“运行时解析硬件描述”。在设备树中声明一个设备节点的典型写法如下iomuxc { pinctrl_led0: led0grp { fsl,pins MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x1b0b0 ; }; }; led { compatible vendor,my-led; pinctrl-names default; pinctrl-0 pinctrl_led0; gpios gpio1 9 GPIO_ACTIVE_LOW; status okay; };当内核启动时platform总线会遍历设备树中的每个节点把节点的compatible属性与驱动的of_match_table字符串进行比较匹配成功则触发probe。这里最常见的坑有两个第一compatible的命名规范。一般格式是“厂商名,设备型号”例如vendor,my-led。很多人随便写一个名字导致匹配不成功驱动probe永远不执行还找不到原因。第二status属性的处理。设备树节点默认是“okay”状态但如果被写成disabled该设备就不会被注册。这在调试时特别容易迷惑开发者——明明驱动和dts都写了但设备节点就是不存在。3.4 几个必须吃透的内核数据结构除了设备模型还有几个数据结构在驱动开发中出现频率极高需要建立直观认知struct file内核中代表一个打开的文件或设备节点几乎所有设备驱动的read/write都会用到。struct inode代表文件系统中的一个文件对象在驱动中常用它来获取设备的私有数据container_of。struct file_operations设备驱动的能力清单定义了设备支持哪些操作。struct cdev字符设备的抽象用于将设备注册进VFS层。struct device一个抽象设备几乎所有的驱动都会与之打交道。struct platform_deviceplatform设备的抽象是设备树节点在驱动模型中的落点。很多人学驱动时对struct file和struct inode分不清楚。简单来说inode是文件本身不管打开几次只有一个file是打开文件的一个实例每次open都会创建一个新的。这两个结构体在驱动开发中贯穿始终初期理解到位后面写复杂驱动时就不会绕弯。4. 内核崩溃日志是最高效的调试老师4.1 第一次看到Oops别慌先学会读日志驱动开发和应用开发最大的区别之一在于应用崩溃最多是segmentation fault驱动崩溃轻则系统报错重则直接死机重启。很多初学者第一次看到内核Oops日志时整个人是蒙的其实Oops日志的格式非常固定只要按顺序读就能快速定位问题。一个典型的Oops日志包含以下关键信息Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ... pc : my_driver_read0x20/0x44 [my_module] lr : vfs_read0x108/0x1a8 Call trace: my_driver_read0x20/0x44 [my_module] vfs_read0x108/0x1a8 ksys_read0x50/0xc8 __arm64_sys_read0x1c/0x28 ...第一行“Unable to handle kernel NULL pointer dereference”告诉你错误类型是空指针解引用地址是0x10意味着访问了结构体偏移0x10处的字段。pc和call trace则给出了崩溃发生的确切位置和函数调用路径。比如my_driver_read0x20/0x44 [my_module]说明崩溃发生在my_driver_read函数偏移0x20处该函数总长度为0x44字节。拿到这些信息后用addr2line或者objdump反汇编模块就能精确定位到源码的哪一行出了问题。这个过程看起来复杂实际操作几次后你会发现内核调试并没有想象中那么可怕。4.2 printk的level划分和动态调试printk是最朴素也最有效的调试手段。它有8个日志级别0-7从KERN_EMERG到KERN_DEBUG。其中pr_info、pr_debug、pr_err这些封装宏在实际开发中更常用。使用pr_debug时需要注意它默认不输出需要开启动态调试或配置CONFIG_DYNAMIC_DEBUG。运行时可以通过debugfs动态控制某个文件或函数的调试信息# 开启drivers/my_driver.c文件的所有调试输出 echo file drivers/my_driver.c p /sys/kernel/debug/dynamic_debug/control这个技巧在项目现场调试时非常管用不用重新编译内核或驱动就能随时打开和关闭特定位置的调试日志。但也要注意printk在高频路径上的开销很大正式发布版本里要把不必要的调试输出去掉否则会影响实时性。4.3 ftrace和kprobe深水区调试的利器当问题不再局限于某个函数内部而是需要搞清楚“这个函数被谁调用、为什么被调用、调用频率是多少”时ftrace是你的首选工具。# 挂载tracefs并查看当前可跟踪的函数 mount -t tracefs nodev /sys/kernel/tracing echo function_graph /sys/kernel/tracing/current_tracer echo my_driver_probe /sys/kernel/tracing/set_graph_function echo 1 /sys/kernel/tracing/tracing_on cat /sys/kernel/tracing/tracekprobe则是一种动态插桩机制可以在任意内核函数入口和出口处探测不需要重新编译内核。配合tracefs的kprobe_events接口可以做到不写内核模块就完成对一个函数的入参、返回值进行观测# 探测函数入口和返回值 echo p:my_probe sys_open filename0x10(%x0) /sys/kernel/tracing/kprobe_events echo r:my_ret sys_open ret$retval /sys/kernel/tracing/kprobe_events echo 1 /sys/kernel/tracing/events/kprobes/enable这些工具的应用开发工程师很少接触但在内核和驱动调试中却是效率神器。新书里如果能把ftrace和kprobe讲清楚对读者的价值绝对会比多讲几个API大得多。4.4 学会复现和二分定位驱动开发调试中最重要的一步其实是复现问题。很多驱动问题尤其是并发类和时序类问题不是必然出现的可能上千次操作才触发一次。这时候光看日志不够还要创造条件让问题更容易复现。常见的复现手段包括用stress-ng制造内存压力、用并发脚本反复读写设备、在特定外设的speedgrade边界条件下压测。每次崩溃后保留完整的dmesg日志和内核版本信息这是后续定位的基础。如果问题只存在于特定硬件版本或特定内核版本我会用git bisect对内核源码进行二分查找圈定引入问题的提交。虽然这个过程有时会持续一两天但比起大海捞针式的读代码二分法仍然高效得多。5. 动手实验的三种路线选择怎么选5.1 路线一纯x86主机虚拟机/容器如果你只是学习字符设备驱动、内核模块开发、并发控制这些不依赖特定硬件特性的内容一台普通的x86电脑配上Linux发行版就足够了。把内核头文件装好写一个简单的hello模块obj-m hello.o KDIR : /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean编译完后用insmod hello.ko加载再通过dmesg查看输出。这个流程虽然简单但能让初学者把“模块编译、加载、卸载”这条链路跑通建立最基础的信心。需要注意的一点是主机内核和模块版本必须严格一致uname -r的输出要和/lib/modules/下的目录名一致否则会报Invalid module format错误。如果你用的是某些特殊发行版或自己编译的主线内核还需要安装对应的linux-headers包。5.2 路线二QEMU模拟ARM开发板当你想体验设备树、platform驱动、中断控制器这些ARM相关特性但没有真实开发板时QEMU是一个非常好的选择。通过QEMU可以启动一个模拟的ARM Linux系统在系统内编译和加载模块。例如启动一个virt机器qemu-system-arm -M vexpress-a9 -kernel zImage \ -dtb vexpress-v2p-ca9.dtb -drive filerootfs.ext4,formatraw \ -append consolettyAMA0 root/dev/mmcblk0 rw -nographic在这个环境里你可以实践编写设备树节点、编写platform驱动、注册中断控制器等操作。QEMU支持的硬件外设虽然没有开发板丰富但对于理解驱动模型和内核初始化流程完全够用。更重要的是QEMU崩溃了可以直接重启调试成本几乎为零。5.3 路线三真实开发板最接近工程实战当你需要接触真实的外设时序、GPIO控制、I2C/SPI通信、DMA性能等工程问题时真实开发板是必须的。目前比较常见的几类选择平台特点适用方向STM32MP1系列双核Cortex-A7资料全有M4协处理器入门到进阶、工控方向NXP i.MX6ULL低成本、教程极多、许多项目采用适合毕业设计/简历项目Raspberry Pi社区活跃、外设资料全适合GPIO/I2C/SPI等基础外设全志/瑞芯微方案性价比高、多媒体能力强适合Linux显示/编解码的应用开发板买到手之后建议第一件事不是跑图形界面而是从SD卡启动最小系统、配置交叉编译环境、写一个GPIO点灯驱动、用示波器或逻辑分析仪观察波形。把这条链路完整打通嵌入式Linux开发的主要工具链就基本掌握了。5.4 一个完整的学习项目建议如果让我给初学者设计一个既能串联知识点又能写进简历的学习项目我会推荐在开发板上实现一个带中断按键、sysfs属性、定时器防抖和用户态配置功能的字符设备驱动。这个项目会用到字符设备注册与file_operations实现request_irq和中断处理tasklet或工作队列完成中断下半部sysfs属性文件的创建和读写内核定时器或hrtimer的使用用户态测试程序的编写每一个环节单独拿出来都不难但连在一起就是一套完整的驱动开发能力证明。别说初学者很多工作了两年的人都不一定能独立完成这个项目。这正是《手把手教你学Linux设备驱动开发》这类书最好的“官方教学目标”。6. 实际项目中大概率会踩的那些坑6.1 中断上下文里做了不能做的事写驱动时最经典的低级错误就是在中断处理函数中调用了可能导致睡眠的函数。中断上下文不能睡眠因为睡眠需要进程调度而中断中没有进程上下文调度器无法正常工作。常见问题包括在中断处理中调用kmalloc(..., GFP_KERNEL)可能睡眠在中断处理中调用mutex_lock可能睡眠在中断处理中调用copy_to_user绝对禁止用户态指针不可直接访问正确的打开方式是在中断里只做标记事件、唤醒等待队列、提交工作队列等快速操作把耗时的数据处理放到下半部tasklet、workqueue或threaded IRQ中处理。static irqreturn_t my_irq_handler(int irq, void *data) { /* 快速处理路径置标志、唤醒等待队列 */ wake_up_interruptible(my_wait_queue); /* 慢速处理路径交给工作队列 */ schedule_work(my_work); return IRQ_HANDLED; }6.2 并发与共享数据的保护驱动开发中有一句至理名言如果没有并发问题那只是你还没遇到。多核CPU、中断嵌套、preempt调度都会导致同一份共享数据被同时访问。保护手段的选择直接决定驱动在压力测试下的稳定性。场景推荐机制原因临界区很短几条指令自旋锁spinlock开销小不允许睡眠临界区较长或需要睡眠互斥锁mutex持锁期间可睡眠但持有时间不能太长读写不对称且读多写少读写锁rwlock/rwsem提高读并发性单CPU上的简单计数atomic_t / RMW指令最小开销自旋锁最大的陷阱是在持有自旋锁时调用sleep类函数会导致死锁或系统崩溃。因为自旋锁持有期间该CPU可能在等待锁的循环里空转如果代码睡眠了其他CPU也无法获取锁可能引发内核死锁。6.3 内存屏障和DMA一致性的隐蔽问题DMA操作中的缓存一致性问题也是驱动开发的经典大坑。CPU有缓存Cache而DMA控制器直接访问物理内存两边对同一块内存的理解可能不一致。如果驱动不做处理可能出现“CPU写入数据后DMA读到的还是旧值”或“DMA写入新数据后CPU读到的还是缓存中的旧值”的情况。解决方案有两种一致性DMA映射dma_alloc_coherent分配时已经保证CPU和DMA对整个缓冲区看到的数据一致适合数据块较小、访问不频繁的场景。流式DMA映射dma_map_single通过dma_sync_single_for_cpu和dma_sync_single_for_device在CPU和设备间切换缓冲区所有权适合大块数据传输。选择哪种方案取决于你的数据流模式。如果方向固定且频率高优先用流式映射如果数据块小且需要频繁读写一致性映射更省心。6.4 设备树兼容性暗藏的“小问题”设备树看似简单但实际开发中兼容相关的bug非常多。除了前面提到的compatible命名不规范还有几个非常容易踩的坑时钟和复用引脚的配置。很多板级bug的根因不在驱动代码而是设备树里的时钟配置错误或pinctrl冲突。比如某个引脚被两个设备同时使用后加载的驱动可能静默失败或者导致整个总线挂掉。reg属性中的地址和大小。reg 0x020c4000 0x1000表示寄存器基地址和映射大小写错会导致ioremap失败或越界访问。这个问题在拷贝修改别人的dts时尤其容易发生——板和板之间的地址可能完全不同。中断号的获取方式。传统平台用platform_get_resource(pdev, IORESOURCE_IRQ, 0)获取中断号但支持设备树后更常见的是使用irq_of_parse_and_map(node, 0)或者platform_get_irq(pdev, 0)。如果设备树中中断属性没有正确引用中断控制器这些接口会返回-EINVAL或0而很多人没有对返回值做有效判断导致后续request_irq(0, ...)失败且难以排查。6.5 模块加载失败时按顺序查这几项在实际用insmod加载模块遇到-1EPERM或Unknown symbol错误时我会按这个顺序排查内核版本和符号版本modversions是否匹配模块依赖的符号是否已经导出并加载用nm查看__ksymtab设备树节点是否存在且状态为okay引脚、时钟等资源是否与其他驱动冲突内核日志dmesg中的具体错误信息Unknown symbol是最常见的问题。如果模块依赖的某个内核符号没有EXPORT_SYMBOL模块会编译通过但加载失败。这时需要确认内核配置中是否包含了对应的符号导出或者改用其他可用的API。这个坑在你使用树外out-of-tree驱动时尤其常见。7. 我给不同基础读者的阅读和使用建议7.1 入门级读者不要试图一次性吃透全部内容如果你是第一次接触Linux驱动开发我建议你把注意力集中在这几个章节字符设备驱动、模块加载卸载、file_operations接口实现、以及一个简单的GPIO控制例程。这几块足够你理解“驱动到底是什么”以及“驱动和应用如何交互”。不要一上来就啃设备树和platform驱动模型也不要纠结DMA一致性和内存屏障。这些内容在第一轮学习中大概率是看山不是山看了后面忘了前面还容易打击信心。先把最简单的例程在板子上跑起来哪怕只是让一个LED按你的命令闪烁那种成就感比读一百页原理都有用。7.2 有一定经验的工程师重点补齐机制理解如果已经写过一些驱动能搞定GPIO和基本外设我建议你关注书中的这些内容内核设备模型、并发控制、中断下半部、调试技巧、DMA映射。这几块是你从“能写驱动”到“能写稳定可靠的高质量驱动”的必经之路。特别是并发控制很多老工程师写的驱动在单任务调试时没有任何问题一旦上多核、高并发、频繁开关中断的场景就随机崩溃多半是并发保护没做对。建议你专门拿出两周时间把所有内核同步原语全部过一遍再结合读写锁、RCU等机制理解各自的使用场景。7.3 高手向把每章的例程当成重构对象如果你已经在做BSP、芯片适配或内核子系统开发这本书的例程对你来说可能相对简单。但你可以换个角度使用它拿到每个例程先不看实现自己按照功能要求在目标内核上编写然后对照书中的实现分析设计差异。驱动开发领域有个特点看似相同的功能不同的人写出来可能性能差几倍稳定性差一个数量级。这种差异往往体现在对内核API的选型、对资源生命周期的管理、对错误路径的处理上。通过重构别人的例程你收获的远比“照着敲一遍”要多。8. 结合新书我对驱动开发这个领域的一点看法看到《手把手教你学Linux设备驱动开发》这样的书出版我的第一反应是“这个方向终于有人认真做了”。驱动开发的教学难度确实大因为它需要同时处理“内核机制”“硬件规格”和“工程实践”三个维度上的复杂度任何一环缺失都会让学生卡住。但驱动开发的回报也大。这个领域有一个特点入门门槛高但一旦跨过去后续的知识增长会非常快。因为驱动开发的套路性很强——你熟练了一个总线的驱动其他总线的驱动大多是“换汤不换药”。理解设备模型和内核机制之后写一个新的外设驱动往往一周之内就能跑通。作为一个从应用开发转行做内核驱动、又在新华三、联发科等公司的驱动团队摸爬滚打多年的“过来人”我深知这一行没有捷径但有高效路径。找到一本主线清晰、例程完整、讲解逻辑符合开发规律的书能为你节省大量自己摸索的时间。从这个角度说这本书的到来对每一位想进入或深耕Linux设备驱动开发领域的工程师都是一件值得高兴的事。如果你已经入手了这本书或正在学习驱动开发我的建议很简单跟着书把例程跑起来然后把例程丢到一边自己重新实现一遍最后再回到书里对照查漏补缺。驱动开发这门手艺看十遍不如写一遍写十遍不如调通一遍。祝大家都能在内核的世界里找到属于自己的成就感。