Linux驱动核心概念(内核模块、设备文件、总线)
学Linux驱动，绕不开内核模块、设备文件、总线这三个“老伙计”。咱们不用死记硬背，把Linux内核想象成一个“超级大公司”，硬件是来入职的“员工”，这三个概念就是公司里的“核心岗位”——各司其职又互相配合，才能让硬件“安分干活”。咱们先想个问题：驱动是内核的一部分，但总不能每次加个驱动就把整个内核重编一遍吧？这就像公司招临时工，不用重新装修办公楼一样。内核模块（后缀为.ko的文件）就是驱动的“临时工身份凭证”，能让驱动“按需入职”（加载）或“随时离职”（卸载），不用动内核的“根基”。它的核心作用就俩：一是“灵活部署”——比如你给开发板加个LED驱动，编译成.ko文件后，用insmod命令一加载，内核就认得了，卸载用rmmod就行；二是“隔离风险”——驱动出问题了，顶多卸载模块，不会让整个内核崩溃，相当于“临时工犯错不影响公司整体运营”。举个直观的代码示例，这是最简化的内核模块框架（不用纠结细节，看结构就行）：#include<linux/module.h>#include<linux/kernel.h>// 模块加载函数（入职报道）staticint __init demo_module_init(void){ printk(KERN_INFO "驱动临时工报道！\n"); return 0;}// 模块卸载函数（离职交接）staticvoid __exit demo_module_exit(void){ printk(KERN_INFO "驱动临时工下班！\n");}// 注册加载/卸载函数module_init(demo_module_init);module_exit(demo_module_exit);// 必要的许可证声明（内核要求）MODULE_LICENSE("GPL");MODULE_DESCRIPTION("Demo Kernel Module");
编译后生成demo.ko，用insmod demo.ko加载，dmesg命令就能看到“报道”日志，这就是内核模块的核心工作逻辑。用户程序想操作硬件，总不能直接跟内核驱动“私聊”吧？就像你想找公司员工办事，得先找前台接待一样。设备文件就是这个“前台”，它藏在/dev目录下，比如/dev/ttyS0（串口）、/dev/input/mouse0（鼠标），让用户能用“读写文件”这种简单操作，间接操控硬件。这里有个关键逻辑：设备文件本身不干活，只是个“转接器”。比如你用echo "1" > /dev/led让LED亮，这个命令先到设备文件，设备文件再把“亮灯”需求转给对应的驱动，驱动再指挥硬件执行。对用户来说，操作硬件和操作普通文本文件没区别，这就是设备文件“屏蔽底层复杂性”的价值。你可能会发现/dev目录下的文件有“主设备号”和“次设备号”，比如crw-rw---- 1 root dialout 4, 64 /dev/ttyS0，其中4是主设备号（对应驱动），64是次设备号（对应具体硬件）。内核就是靠主设备号找到对应的驱动，再靠次设备号定位到具体的硬件设备，相当于“前台先问清你要找哪个部门（主设备号）、哪个员工（次设备号）”。Linux里有各种各样的硬件（摄像头、传感器、U盘），也有对应的一堆驱动，怎么让它们精准“配对”？这就需要总线这个“红娘”了。总线的核心工作就是“匹配设备和驱动”，构成“总线-设备-驱动”三元架构，这也是Linux驱动模型的基石。- 1. 设备接入时，总线先给它做“身份登记”（生成struct device结构体），记录设备的ID、资源（比如内存地址、中断号）；
- 2. 驱动注册时，会告诉总线“我能搞定哪些设备”（声明支持的设备ID）；
- 3. 总线遍历设备和驱动列表，找到ID匹配的一对，就把它们“绑定”，之后驱动就能正式操控设备了。
这里要提个特殊情况：有些硬件（比如SoC上的GPIO）没有实际的物理总线，内核就虚拟出“platform总线”来当它们的“红娘”，这也是MTK、高通等平台最常用的总线类型。常见的还有I2C总线（传感器常用）、USB总线（U盘常用），它们的“匹配规则”不同，但核心都是“牵线搭桥”。举个USB鼠标插入的例子：插入后USB总线检测到新设备，读取设备的Vendor ID和Device ID，然后遍历已注册的USB驱动，找到支持该ID的鼠标驱动，完成绑定后，驱动再创建/dev/input/mouse0设备文件，用户就能用鼠标了——这就是总线的完整“牵线”流程。内核模块是驱动的“灵活载体”，让驱动能动态加载到内核；总线是驱动和设备的“匹配桥梁”，让它们精准配对；设备文件是用户和硬件的“交互入口”，让操作硬件更简单。整个流程就是：用户程序→设备文件→驱动（内核模块）→总线→硬件，环环相扣，这就是Linux驱动工作的核心逻辑。
10个月宝宝每天需要喝多少奶粉？
