1. 为什么“不碰硬件”反而是驱动开发最该先啃的骨头
很多人一听到“驱动程序开发”，脑子里立刻浮现出示波器、逻辑分析仪、焊台、飞线，还有一块被反复插拔到金手指发黑的开发板。这个联想不能说错，但它把驱动开发的门槛人为抬高了。真实情况是，一个驱动工程师日常写的代码里，有相当大的比例根本不直接操作寄存器，也不关心某个引脚是高电平还是低电平。这部分工作，恰恰是驱动开发中最通用、最可迁移、也最适合在没有任何硬件的情况下练手的部分。
我见过不少初学者，手里没有板子就觉得自己学不了驱动，于是把时间全花在背寄存器手册上，结果真拿到硬件反而不知道从哪下手。也见过另一类人，一上来就买一堆模块，照着教程把灯点亮了，但问他“这个驱动是怎么被系统加载的”“设备节点是怎么冒出来的”，完全答不上来。这两类问题的根源是同一个：跳过了“不涉及硬件”的那一层抽象。
所谓“不涉及硬件”的驱动开发，指的是驱动代码中与具体硬件寄存器、时序、电气特性无关的那部分逻辑。它包含驱动的注册与注销、设备与驱动的匹配、字符设备或杂项设备的框架搭建、文件操作集合的填充、用户空间与内核空间的数据交换、并发控制、内存管理、模块参数、日志与调试接口等等。这些东西在任何一块板子上都是同一套写法，换一个平台几乎不用改。你完全可以在纯软件环境里把它们全部跑通、调透。
这篇文章面向的是想入门驱动开发但手头没有硬件、或者有硬件但想先把框架层吃透的人。我会把“不涉及硬件”这条路线拆成几个可以独立推进的模块，讲清楚每一步为什么这么做、常见做法是什么、以及我在实际写这类代码时踩过的坑。文中所有代码示例都是框架性质的，不绑定任何具体芯片，你可以直接在自己的环境里编译加载验证。
需要提前说明的是，虽然不碰硬件，但你仍然需要一个能加载内核模块的环境。最省事的做法是在虚拟机里装一个和你当前系统匹配的内核源码与头文件，用insmod和rmmod来验证模块的加载卸载。这个环境搭建本身也是“不涉及硬件”的一部分，后面会专门讲。
2. 把驱动拆开看：哪些部分天生与硬件无关
2.1 驱动代码的分层结构决定了可分离性
一个典型的驱动，从代码组织上看大致可以分成三层。最上层是“接口层”，负责向内核注册自己，告诉内核“我是一个字符设备”或者“我是一个杂项设备”，并填充内核要求的各种结构体。中间层是“逻辑层”，处理用户空间发来的读写请求、做参数校验、管理内部状态、处理并发。最下层才是“硬件层”，真正去读写寄存器、等待中断、操作DMA。
这三层里，接口层和逻辑层几乎完全与硬件无关。接口层的写法由内核API决定，逻辑层由业务需求决定，只有硬件层才依赖具体芯片。很多教程一上来就讲硬件层，是因为点灯最直观，但代价是初学者被寄存器细节淹没，看不到驱动的整体骨架。
我个人的习惯是，拿到一个新驱动任务时，先把接口层和逻辑层用“假硬件”写出来。所谓假硬件，就是用一块内核里分配的内存缓冲区来模拟设备的数据区。用户写进来的数据存到这块缓冲区，用户读出去的数据也从这块缓冲区取。整个数据通路是通的，但没有任何真实硬件参与。等这部分调稳了，再把假硬件替换成真实的寄存器操作。这样做的好处是，当驱动出问题时，你能确定问题出在框架层还是硬件层，而不是一锅粥地猜。
2.2 字符设备框架：最经典的“无硬件”练手场
字符设备是Linux驱动里最基础的一类。它的核心结构是file_operations，里面是一堆函数指针，对应open、read、write、release这些系统调用。内核在用户调用这些系统调用时，会找到对应的驱动函数来执行。
一个最小的、完全不涉及硬件的字符设备驱动，大致长这样：
#include <linux/module.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/uaccess.h> #define DEVICE_NAME "demo_char" #define BUF_SIZE 1024 static int major; static struct cdev demo_cdev; static char demo_buf[BUF_SIZE]; static int demo_len; static int demo_open(struct inode *inode, struct file *filp) { return 0; } static ssize_t demo_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { int ret; if (*ppos >= demo_len) return 0; if (count > demo_len - *ppos) count = demo_len - *ppos; ret = copy_to_user(buf, demo_buf + *ppos, count); if (ret) return -EFAULT; *ppos += count; return count; } static ssize_t demo_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { int ret; if (count > BUF_SIZE) count = BUF_SIZE; ret = copy_from_user(demo_buf, buf, count); if (ret) return -EFAULT; demo_len = count; return count; } static int demo_release(struct inode *inode, struct file *filp) { return 0; } static struct file_operations demo_fops = { .owner = THIS_MODULE, .open = demo_open, .read = demo_read, .write = demo_write, .release = demo_release, }; static int __init demo_init(void) { dev_t dev; int ret; ret = alloc_chrdev_region(&dev, 0, 1, DEVICE_NAME); if (ret < 0) return ret; major = MAJOR(dev); cdev_init(&demo_cdev, &demo_fops); demo_cdev.owner = THIS_MODULE; ret = cdev_add(&demo_cdev, dev, 1); if (ret < 0) { unregister_chrdev_region(dev, 1); return ret; } return 0; } static void __exit demo_exit(void) { dev_t dev = MKDEV(major, 0); cdev_del(&demo_cdev); unregister_chrdev_region(dev, 1); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE("GPL");这段代码里没有任何一行碰硬件。它做的事情是：申请一个设备号，初始化一个cdev并加入内核，填充file_operations。用户空间通过设备节点读写时，数据在demo_buf这块内存里进出。你可以用mknod创建节点，然后echo和cat来验证。
为什么先写这个？因为它把驱动开发里最容易出错的一类问题——框架注册与注销的顺序、错误路径的资源释放——暴露出来了。比如上面init函数里，如果cdev_add失败，必须把之前申请的设备号释放掉，否则模块卸载后设备号泄漏。这种错误在真实硬件驱动里同样存在，而且更难排查，因为你会怀疑是硬件问题。
2.3 杂项设备：更省事的注册方式
字符设备要自己申请设备号、自己创建设备节点，步骤偏多。杂项设备（misc device）是内核提供的一个简化框架，它自动分配设备号，主设备号固定为10，你只需要提供一个次设备号和file_operations。对于功能单一、不需要多个设备实例的驱动，用杂项设备能省掉不少样板代码。
#include <linux/miscdevice.h> static struct miscdevice demo_misc = { .minor = MISC_DYNAMIC_MINOR, .name = "demo_misc", .fops = &demo_fops, }; static int __init demo_init(void) { return misc_register(&demo_misc); } static void __exit demo_exit(void) { misc_deregister(&demo_misc); }就这么几行。misc_register内部帮你做了设备号的申请和cdev的添加，misc_deregister帮你做清理。对于“不涉及硬件”的练手项目，我通常建议从杂项设备入手，因为它把框架层的噪音降到最低，让你专注于file_operations里的逻辑。
但这里有个坑要注意：杂项设备的file_operations里，open和release不是必须的，但如果你不实现，内核会用默认的。默认行为在大多数情况下没问题，但如果你需要在打开设备时做初始化、在关闭时做清理，就必须自己实现。我见过有人在open里分配内存，却忘了在release里释放，结果反复打开关闭几次之后内存就耗尽了。这种问题在纯软件环境里很容易复现，正好用来练手。
3. 用户空间与内核空间的数据交换：copy_to_user和copy_from_user的门道
3.1 为什么不能直接memcpy
用户空间的指针在内核里不能直接解引用。原因有两层：一是地址空间隔离，用户进程的虚拟地址在内核页表里不一定有对应映射；二是安全，用户可能传进来一个恶意指针，直接访问会导致内核崩溃或者被利用。
所以内核提供了copy_to_user和copy_from_user这两个函数，它们会做地址合法性检查，并且在访问失败时返回未拷贝的字节数。注意返回值是“没拷贝成功的字节数”，不是错误码。很多初学者写成：
if (copy_to_user(buf, src, count)) { return -EFAULT; }这样写逻辑上没错，因为只要返回值非零就说明有字节没拷成功。但更严谨的写法是判断返回值是否等于count，或者直接用返回值做后续处理。我个人的习惯是，对于必须全部成功的场景，判断非零就返回-EFAULT；对于允许部分成功的场景，用返回值计算实际拷贝量。
3.2 方向别搞反
copy_to_user是从内核拷到用户，copy_from_user是从用户拷到内核。这两个名字是以“用户空间”为参照的：to_user就是“到用户去”，from_user就是“从用户来”。我见过有人在write函数里用copy_to_user，结果数据方向反了，用户写进来的数据被覆盖成了缓冲区里的旧数据。这种bug在纯软件环境里表现为“写进去读出来不对”，很容易定位；但如果是在真实硬件驱动里，你可能以为是硬件没响应。
3.3 数据量边界与部分拷贝
copy_to_user和copy_from_user的第三个参数是字节数。这个字节数必须经过校验，不能直接信任用户传进来的count。比如你的缓冲区只有1024字节，用户传进来一个count为4096的write请求，你必须把count截断到1024，否则copy_from_user会越界写内核内存。
上面示例代码里的if (count > BUF_SIZE) count = BUF_SIZE;就是做这件事。但这里还有个细节：截断之后，write函数返回的是截断后的count还是原始的count？按照POSIX的惯例，write应该返回实际写入的字节数。如果你截断了，就应该返回截断后的值，让用户知道只写进去了一部分。有些驱动直接返回原始count，用户以为全写进去了，实际上只写了一部分，后续读出来数据对不上，排查起来很费劲。
3.4 一个容易忽略的点：用户缓冲区的可访问性
copy_to_user和copy_from_user在访问用户内存时，可能会因为缺页而睡眠。这意味着它们不能在原子上下文（比如中断处理程序、持有自旋锁的代码段）里调用。在“不涉及硬件”的练手阶段，你写的read和write都是在进程上下文里被调用的，睡眠没问题。但如果你后面要加一个定时器或者工作队列来模拟“硬件事件”，就要注意不要在原子上下文里碰这两个函数。
我建议在练手阶段就养成习惯：凡是可能睡眠的操作，都放在进程上下文或者工作队列里做。这样等以后接真实硬件时，中断处理程序里只做最小必要的事情，把数据拷贝这类可能睡眠的操作丢给下半部。
4. 并发控制：没有硬件中断，照样有竞态
4.1 竞态不只来自硬件
很多人以为竞态是硬件中断引起的，没有硬件就没有竞态。这是错的。只要有多条执行路径可能同时访问同一份数据，就有竞态。在你的字符设备驱动里，多个进程可以同时open同一个设备节点，然后同时调用read和write。这些系统调用在内核里可能在不同的CPU上并行执行，也可能因为调度而交错执行。demo_buf和demo_len这两个全局变量就是共享数据，没有保护就会有竞态。
举个具体的场景：进程A调用write写入500字节，进程B同时调用write写入300字节。如果没有保护，demo_len的更新可能交错，最终demo_len的值可能是500、300或者某个中间值，而demo_buf里的内容可能是两次写入的混合。用户读出来的数据就是乱的。
4.2 互斥锁：最常用的保护手段
对于这种可能睡眠的上下文，互斥锁（mutex）是首选。它的特点是获取不到锁时会睡眠，不会忙等，适合保护较长的临界区。
#include <linux/mutex.h> static DEFINE_MUTEX(demo_mutex); static ssize_t demo_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { int ret; if (count > BUF_SIZE) count = BUF_SIZE; if (mutex_lock_interruptible(&demo_mutex)) return -ERESTARTSYS; ret = copy_from_user(demo_buf, buf, count); if (ret) { mutex_unlock(&demo_mutex); return -EFAULT; } demo_len = count; mutex_unlock(&demo_mutex); return count; }这里用mutex_lock_interruptible而不是mutex_lock，是因为前者在等待锁的过程中如果收到信号，会返回错误让调用者有机会退出。对于用户触发的操作，用可中断版本更友好。如果是在内核线程里做后台操作，用不可中断版本也可以。
4.3 自旋锁：什么时候不该用
自旋锁（spinlock）在获取不到锁时会忙等，不睡眠。它的适用场景是临界区极短、且不能睡眠的上下文，比如中断处理程序。在“不涉及硬件”的练手阶段，你的read和write都在进程上下文，临界区里还有copy_from_user这种可能睡眠的操作，所以绝对不能用自旋锁。用了自旋锁再在里面睡眠，轻则警告，重则死锁。
我见过有人在字符设备驱动里用自旋锁保护整个write函数，包括copy_from_user。在单核且没有抢占的配置下可能侥幸能跑，但一旦开启抢占或者跑到多核上，就会出问题。这种代码在纯软件环境里用压力测试（多个进程同时读写）就能暴露出来，正好作为练手内容。
4.4 原子变量：只适合简单计数
如果你的共享数据只是一个计数器，比如记录设备被打开了多少次，可以用原子变量（atomic_t）。原子变量的操作不会睡眠，也不需要锁，但它的能力仅限于简单的读改写。一旦你的临界区涉及多个变量的协同修改，原子变量就不够了，必须用锁。
选择哪种保护机制，判断标准是：临界区里有没有可能睡眠的操作？有就用互斥锁，没有且临界区极短可以用自旋锁，只是简单计数可以用原子变量。这个判断逻辑在有无硬件的情况下都一样。
5. 模块参数与调试接口：让驱动可配置、可观测
5.1 module_param：不重新编译就能改配置
驱动开发中经常需要调整一些参数，比如缓冲区大小、设备名称、调试开关。如果每次改参数都要重新编译模块，效率太低。内核提供了module_param宏，可以把模块里的全局变量暴露成加载时可指定的参数。
static int buf_size = 1024; module_param(buf_size, int, 0644); MODULE_PARM_DESC(buf_size, "Size of the internal buffer"); static bool debug_enable = false; module_param(debug_enable, bool, 0644); MODULE_PARM_DESC(debug_enable, "Enable debug logging");加载时用insmod demo.ko buf_size=2048 debug_enable=1就能覆盖默认值。第三个参数是sysfs里的权限，0644表示用户可读、root可写。如果你希望在运行时也能通过sysfs修改参数，权限要设成0644；如果只希望在加载时指定，可以用0。
这里有个细节：module_param的变量类型必须和宏的第一个参数匹配。int对应int，bool对应bool，charp对应char*。类型不匹配会导致编译警告或者运行时行为异常。我见过有人把char数组用module_param声明成charp，结果加载时直接崩溃，因为内核会把它当成指针去解引用。
5.2 sysfs接口：运行时的观测窗口
module_param提供的是加载时的配置，如果要在运行时查看驱动内部状态，sysfs是更合适的接口。通过DEVICE_ATTR宏可以创建属性文件，用户cat这个文件就能触发你的show函数，echo就能触发store函数。
static ssize_t status_show(struct device *dev, struct device_attribute *attr, char *buf) { return sprintf(buf, "len=%d\n", demo_len); } static DEVICE_ATTR_RO(status);然后在probe或者init里用device_create_file创建这个属性。对于杂项设备，可以用misc_register之后拿到的device指针来创建。
sysfs接口的价值在于，它让你在不加printk、不重新加载模块的情况下，随时查看驱动内部状态。在“不涉及硬件”的阶段，你可以用sysfs来观测缓冲区里有多少数据、设备被打开了多少次、最后一次操作是什么类型。这些信息在调试真实硬件驱动时同样有用，因为硬件的行为你没法直接看到，只能通过驱动暴露的接口来推断。
5.3 printk与动态调试
printk是最直接的调试手段，但它有个问题：日志级别控制不好会刷屏，控制太严又看不到关键信息。我通常的做法是定义一个debug_enable模块参数，在需要打印的地方用条件判断包起来：
#define demo_dbg(fmt, ...) \ do { if (debug_enable) pr_info("demo: " fmt, ##__VA_ARGS__); } while (0)这样默认不打印，需要时加载模块带上debug_enable=1即可。比动态调整printk级别更可控。
另外，pr_fmt宏可以给所有printk加上统一前缀，方便在dmesg里过滤。在文件开头定义#define pr_fmt(fmt) "demo: " fmt，之后所有pr_info、pr_err都会自动带上“demo: ”前缀。这个习惯在驱动代码变多之后尤其有用，因为dmesg里会混着各种子系统的日志，没有前缀很难分辨哪条是你的驱动打的。
6. 从假硬件到真硬件的过渡：接口抽象的价值
6.1 把硬件操作收敛到一组函数里
当你在“不涉及硬件”阶段把框架层和逻辑层调稳之后，接真实硬件时要做的事情其实很有限：把原来操作demo_buf的地方，替换成操作硬件的函数。为了让这个替换尽可能平滑，我建议在写假硬件版本时就把硬件操作抽象成一组函数：
static int hw_read(char *buf, int len); static int hw_write(const char *buf, int len); static int hw_init(void); static void hw_exit(void);在假硬件版本里，这些函数的实现就是操作内存缓冲区。在真实硬件版本里，它们变成读写寄存器、等待状态位。上层的file_operations和并发控制完全不用改。
这种抽象的好处不只是方便替换。它强迫你思考“硬件到底需要提供什么能力”，而不是一上来就陷入寄存器细节。很多时候，把接口定义清楚了，硬件操作本身反而是最简单的部分。
6.2 假硬件也能模拟时序和错误
有人可能会说，假硬件太理想化了，真实硬件会有延迟、会出错、会有各种边界情况。这话没错，但假硬件也可以模拟这些。比如你可以在hw_read里加一个usleep_range来模拟读取延迟，在hw_write里随机返回错误来模拟写入失败。这样上层逻辑对延迟和错误的处理就能在纯软件环境里得到验证。
我在实际项目中就吃过这个亏：假硬件阶段一切顺利，接上真实硬件后发现读取偶尔会超时，而上层代码完全没有处理超时的逻辑，导致整个驱动卡死。后来我在假硬件里加了随机延迟和随机失败，把上层的重试和超时处理补上了，再接真实硬件就顺利多了。
6.3 设备树与ACPI：硬件信息的描述
真实硬件驱动还需要从设备树或ACPI获取硬件信息，比如寄存器基地址、中断号、时钟频率。这部分在“不涉及硬件”阶段可以先跳过，但你要知道它的存在。设备树里的compatible属性用来匹配驱动，of_device_id表用来声明驱动支持哪些设备。这些匹配机制和字符设备的file_operations一样，属于框架层的东西，可以在没有硬件的情况下先理解清楚。
我建议在练手阶段就把驱动的匹配表写好，哪怕暂时用不上。这样等接真实硬件时，你只需要填上正确的compatible字符串，匹配逻辑本身不用再动。
7. 实操中容易翻车的几个细节
7.1 模块卸载时的资源释放顺序
模块卸载函数里，资源的释放顺序必须和申请顺序相反。先申请的后释放，后申请的先释放。比如你先alloc_chrdev_region再cdev_add，卸载时就要先cdev_del再unregister_chrdev_region。顺序反了会导致内核警告甚至崩溃。
这个规则在有无硬件的情况下都一样，但在“不涉及硬件”阶段更容易验证：加载模块、卸载模块、再加载、再卸载，反复几次，看dmesg里有没有警告。如果有资源泄漏，反复加载卸载之后设备号会耗尽，或者内存会越来越少。
7.2 错误路径的清理
init函数里如果有多个步骤，每一步失败都要把之前成功的步骤回滚。这是驱动代码里最容易写错的地方，因为正常路径只有一条，错误路径有很多条。我通常用一个goto链来组织：
static int __init demo_init(void) { int ret; ret = step1(); if (ret) return ret; ret = step2(); if (ret) goto err_step1; ret = step3(); if (ret) goto err_step2; return 0; err_step2: undo_step2(); err_step1: undo_step1(); return ret; }这种写法看起来有点老派，但在内核代码里非常常见，因为它把清理逻辑集中在一起，不容易漏。用goto在用户空间代码里可能被诟病，但在内核里是标准做法。
7.3 设备节点的创建与权限
用字符设备框架时，设备节点需要手动mknod或者用udev规则自动创建。手动mknod的话，主设备号要从/proc/devices里查，次设备号自己定。权限默认是root可读写，普通用户访问不了。如果希望普通用户也能访问，要么改节点权限，要么写udev规则。
杂项设备会自动在/dev下创建节点，权限由内核默认规则决定。如果需要特定权限，可以在udev规则里指定。在“不涉及硬件”阶段，用root权限测试就行，但要知道权限这回事的存在，免得接真实硬件后因为权限问题以为驱动没工作。
7.4 内核版本差异
内核API在不同版本之间会有变化。比如file_operations里的read和write，在老版本里返回值类型是ssize_t，新版本也是，但某些辅助函数的签名可能不同。copy_to_user的返回值处理方式在不同版本里也有细微差别。
我的建议是，练手时就用你当前运行内核对应的头文件来编译，不要抄网上针对其他版本的代码。如果编译报错，先查你本机/usr/src下的头文件里这个函数的原型，以本机为准。内核代码的向后兼容性没有用户空间那么好，跨版本抄代码是常见的翻车原因。
8. 把“不涉及硬件”的练习串成一个完整项目
单独看每个知识点都不难，但驱动开发的能力体现在把它们串起来。我建议用一个完整的练手项目来收尾：实现一个字符设备驱动，它有一个内部缓冲区，支持多进程并发读写，有互斥锁保护，有模块参数控制缓冲区大小和调试开关，有sysfs接口暴露当前状态，有完整的错误处理和资源清理。整个项目不碰任何硬件，但结构和一个真实驱动完全一样。
这个项目做完之后，你对驱动框架的理解会超过很多只会点灯的人。因为点灯只需要照着教程改几个寄存器值，而框架层的这些东西，是每个驱动都要面对的。等真正拿到硬件时，你只需要把hw_read和hw_write这两个函数替换掉，剩下的代码几乎不用动。
我在带新人的时候，通常要求他们先把这个纯软件版本写出来，能反复加载卸载不出警告，能用多进程压力测试不出错，能用sysfs看到内部状态。做到这几点之后，再给他们一块板子，往往半天就能把真实硬件跑通。反过来，如果直接上硬件，很多人会在框架层的问题和硬件层的问题之间反复横跳，效率反而低。
最后分享一个我自己的习惯：每写一个新驱动，先不写硬件操作，而是用假硬件把整个数据通路跑通，用echo和cat验证读写，用多个终端同时读写验证并发，用dmesg确认没有警告。这一步花的时间，在接真实硬件之后会加倍省回来。因为硬件的问题往往更隐蔽，如果框架层还有一堆没发现的bug，排查起来就是双重困难。把能确定的部分先确定下来，剩下的不确定性才可控。
