现代字符设备驱动应使用alloc_chrdev_region + cdev_init + cdev_add组合替代register_chrdev：前者支持动态分配设备号、精细管理次设备号并适配新内核机制，后者仅适用于主设备号
字符设备驱动的核心注册流程（register_chrdev vs alloc_chrdev_region）
Linux 字符设备驱动不能靠简单调用 register_chrdev 就完事——它只适用于主设备号小于 256 的静态注册，且不支持设备号动态分配和更精细的 cdev 管理。现代驱动应优先用 alloc_chrdev_region + cdev_init + cdev_add 组合，否则在内核 5.10+ 上可能触发警告或无法创建设备节点。
实操要点：
-
alloc_chrdev_region必须在module_init中尽早调用，失败时立即返回，避免后续内存泄漏 -
cdev_init后必须显式设置cdev.owner = THIS_MODULE，否则卸载模块时内核会 panic（常见于忘记这行） -
cdev_add的第三个参数是设备号数量（通常为 1），若传 0 会导致-EINVAL错误，dmesg里看到 "cdev_add failed" 就先查这个
用户态读写如何触发内核回调（read/write 函数签名与原子性）
用户调用 read() 或 write() 时，内核最终执行你注册在 file_operations 结构体里的 read 和 write 成员函数。这两个函数签名和语义与 libc 不同：它们不保证一次完成全部 count 字节，必须返回实际处理字节数，且不能直接访问用户地址空间。
关键细节：
立即学习“C++免费学习笔记（深入）”；
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 必须用
copy_from_user（写入内核）和copy_to_user（读出到用户）做地址空间转换，直接解引用buf指针会 oops - 函数返回值是“成功传输的字节数”，不是 0/1 成败标志；返回负值（如
-EFAULT）表示错误，会被用户态read返回 -1 并置errno - 不要在
read/write里睡眠（比如用msleep），除非已将文件设为非阻塞且使用了等待队列——默认上下文是不可调度的原子上下文
设备节点怎么自动创建（class_create + device_create）
仅注册 cdev 不会生成 /dev/xxx 节点，用户态根本打不开。必须配合 class_create 和 device_create 让 udev 触发节点创建。跳过这步，mknod 手动建节点虽能用，但不符合现代驱动规范，且重启后消失。
常见坑：
-
class_create的第二个参数是 owner，必须传THIS_MODULE，否则模块卸载时 class 释放失败，dmesg 报 "class_destroy called on a class with children" -
device_create第四个参数（void *drvdata）可传NULL，但第五个参数（name）不能含路径或斜杠，否则udev创建节点失败，ls /dev看不到 - 务必在
module_exit中按反序调用device_destroy→class_destroy→unregister_chrdev_region，顺序错会导致rmmod卡住或警告
为什么 ioctl 比 read/write 更适合控制类操作
如果需要传递命令、配置寄存器、切换模式等非流式操作，硬塞进 read/write 逻辑会混乱且难维护。此时应实现 ioctl，它专为“控制”设计，参数明确（cmd + arg），且内核已帮你做了用户空间地址校验（对 _IO、_IOR、_IOW 宏定义的 cmd）。
注意事项：
- 用
_IOWR宏定义命令时，size 参数必须与用户传入结构体大小严格一致，否则copy_from_user可能越界或截断 - 不要在
ioctl里调用可能阻塞的函数（如wait_event_interruptible）而不检查current->signal->pending，否则用户Ctrl+C无法中断 ioctl 调用 - 若需支持 32/64 位混合环境（比如 x86_64 内核跑 32 位用户程序），必须实现
compat_ioctl，否则 32 位程序调用会直接返回-ENOTTY
真正麻烦的从来不是注册或读写，而是并发访问时的数据竞争——哪怕只是两个线程同时 write，没加锁就可能把内核缓冲区搞乱。别指望用户态同步，驱动里该用 spin_lock_irqsave 的地方一个都不能少。
