嵌入式Linux驱动教程——字符设备驱动简介嵌入式Linux驱动教程——字符设备驱动简介与硬件对话的艺术有一类问题，

嵌入式Linux驱动教程——字符设备驱动简介

仓库已经开源！所有教程，主线内核移植，跑新版本imx-linux/uboot都在这里！欢迎各位大佬观摩！喜欢的话点个⭐！

仓库地址：github.com/Awesome-Emb…

静态网页：awesome-embedded-learning-studio.github.io/imx-forge/

经过相当长的时间，驱动教程终于可以慢慢跟大家见面了！我们将从老内核（4.1.15）出发，看看NXP的Linux IMX内核（6.12.49）和现代内核（7.0）中，驱动的体系发生了哪一些变化！

与硬件对话的艺术

有一类问题，表面上看是「怎么写代码」的问题，实际上是「怎么对话」的问题。我们在这一章要处理的，正是这样一个问题。

想象一下，你坐在一台巨大的、轰鸣的机器面前——这块 ARM 开发板就是那台机器。你想让它点亮一盏灯，或者读取一个按键的状态。但在你和这台机器之间，隔着一道厚厚的墙：这道墙叫「用户空间」与「内核空间」。你在墙这边敲代码，机器在墙那边转齿轮。

你怎么让墙那边的齿轮听你的指挥？

在 Linux 的设计哲学里，答案既霸道又优雅：把一切东西都文件化。不管你是复杂的显卡、简单的 LED，还是虚无缥缈的随机数生成器，只要你想用，就得在 /dev 目录下给我变出一个文件来。

这一章，我们要做的就是编写那个「把硬件变成文件」的翻译官——字符设备驱动。它是 Linux 驱动中最基本、最经典的一类。理解了它，你就拿到了内核驱动开发大门的钥匙。

字符设备：字节流的哲学

首先得搞清楚我们要对付的是个什么玩意儿。

Linux 里的设备驱动分好几种，字符设备是最基本的一类。什么叫「字符设备」？说白了，就是那种按照字节流来读写、还得讲究个先来后到的设备。

这就好比你在读一本书（或者写日记），你必须从第一页第一个字开始，一行一行地来。你不能说「我要读取第 500 个字」，直接跳过去（那是块设备干的事，比如硬盘）。

我们在嵌入式里最常打交道的那几位——点灯、按键、IIC、SPI、LCD ——统统都是字符设备。它们的数据传输就像是流水线上的零件，一个接一个，顺序不能乱。

系统调用：穿越那道墙

在深入代码细节之前，我们需要先建立一个大局观。

当你在应用程序里写下 open("/dev/led", ...) 这行代码的时候，实际上发生了一场跨越边界的旅行。这场旅行涉及四个层级，就像下图中展示的那样：

[ 应用程序 ]  open(), read(), write()
      ↓
[ C 库 ]       对应的库函数 (libc)
      ↓ (系统调用 System Call)
[ 内核 ]       驱动中的 open(), read(), write()
      ↓
[ 硬件 ]       具体的寄存器和物理设备

Linux 的铁律是：应用程序运行在用户空间，驱动运行在内核空间。

用户空间是无权直接触碰内核空间的——这就像你不能随便走进核电站的控制室。如果你想进去，必须通过一个特殊的「安检通道」，这个通道就叫系统调用。

这里的流程是：

应用程序 调用 open() 函数。
这个 open() 其实是 C 库（比如 glibc）提供的封装。
C 库执行一段汇编代码（软中断），引发 CPU 模式切换，从用户态陷入到内核态。
内核根据你打开的文件路径（比如 /dev/led），找到对应的驱动程序。
驱动程序里真正干活的 open() 函数被执行。

但在这里有个有趣的事情：名字是一样的。

你在应用层调用 open，驱动层也得有一个叫 open 的函数在那等着。这种「同名呼应」不是巧合，而是 Linux 内核为了降低认知负担特意设计的——你在这一头喊话，那一头有个同样名字的人在听。

file_operations：驱动的「队员名单」

现在我们走到内核里。既然应用层调用 open、read、write，那驱动层怎么知道把这些调用映射到哪段代码上呢？

答案是靠一个核心的数据结构：file_operations。

你可以把这个结构体理解为一支足球队的队员名单，或者一张 vtable（虚函数表）。它是一个巨大的函数指针集合，里面罗列了驱动能响应的所有动作。

这个结构体定义在内核源码 include/linux/fs.h 文件里，长得非常壮观。我们把它拆开来看，别被它吓到了。

老内核（4.1.15）的 file_operations

struct file_operations {
    struct module *owner;               /* 拥有该结构的模块，通常为 THIS_MODULE */
    loff_t (*llseek) (struct file *, loff_t, int); /* 修改当前读写位置 */
    ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); /* 读取设备 */
    ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); /* 写入设备 */
    ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
    ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
    int (*iterate) (struct file *, struct dir_context *);
    unsigned int (*poll) (struct file *, struct poll_table_struct *); /* 轮询，非阻塞IO用 */
    long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); /* 控制命令 */
    long (*compat_ioctl) (struct file *, unsigned int, unsigned long); /* 32位兼容 */
    int (*mmap) (struct file *, struct vm_area_struct *); /* 内存映射，LCD显存常用 */
    int (*open) (struct inode *, struct file *);       /* 打开设备 */
    int (*flush) (struct file *, fl_owner_t id);
    int (*release) (struct inode *, struct file *);    /* 关闭设备，对应close */
    int (*fsync) (struct file *, loff_t, loff_t, int datasync);
    int (*aio_fsync) (struct kiocb *, int);
    int (*fasync) (int, struct file *, int);
    int (*lock) (struct file *, int, struct file_lock *);
    ssize_t (*sendpage)(struct file *, struct page *, int, size_t, loff_t *, int);
    unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
    int (*check_flags)(int);
    int (*flock) (struct file *, int, struct file_lock *);
    ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
    ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
    int (*setlease)(struct file *, long, struct file_lock **, void **);
    long (*fallocate)(struct file *file, int mode, loff_t offset, loff_t len);
    void (*show_fdinfo)(struct seq_file *m, struct file *f);
};

新内核（6.12.49 / 7.0.0-rc4）的 file_operations

struct file_operations {
    struct module *owner;
    fop_flags_t fop_flags;              /* 新增：文件操作标志位 */
    loff_t (*llseek) (struct file *, loff_t, int);
    ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
    ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
    ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
    int (*iopoll)(struct kiocb *kiocb, struct io_comp_batch *, unsigned int flags);
    int (*iterate_shared) (struct file *, struct dir_context *);
    __poll_t (*poll) (struct file *, struct poll_table_struct *);
    long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
    long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
    int (*mmap) (struct file *, struct vm_area_struct *);
    int (*open) (struct inode *, struct file *);
    int (*flush) (struct file *, fl_owner_t id);
    int (*release) (struct inode *, struct file *);
    int (*fsync) (struct file *, loff_t, loff_t, int datasync);
    int (*fasync) (int, struct file *, int);
    int (*lock) (struct file *, int, struct file_lock *);
    unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned int);
    int (*check_flags)(int);
    int (*flock) (struct file *, int, struct file_lock *);
    ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
    ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
    void (*splice_eof)(struct file *file);
    int (*setlease)(struct file *, int, struct file_lease **, void **);
    long (*fallocate)(struct file *file, int mode, loff_t offset, loff_t len);
    void (*show_fdinfo)(struct seq_file *m, struct file *f);
    ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, loff_t, size_t, unsigned int);
    loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in, struct file *file_out, loff_t pos_out, loff_t len, unsigned int remap_flags);
    int (*fadvise)(struct file *, loff_t, loff_t, int);
    int (*uring_cmd)(struct io_uring_cmd *ioucmd, unsigned int issue_flags);
    int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *, unsigned int poll_flags);
} __randomize_layout;

关键变化对比

别看它有一大堆成员，真正在开发字符设备时必须实现的，其实就那么几个。就像球队里虽然报了 20 个人，但上场的始终是那几个主力。（嗯，听着有点令人伤心）

核心成员（新老内核通用）：

owner：这不是函数指针，是一个指向模块的指针。它用来防止驱动还在运行时就被意外卸载了。标准写法永远是 THIS_MODULE。记住，这行字是防止内核崩溃的安全带。
read： 核心成员。应用程序调用 read() 时，最终执行的就是这个函数指针指向的代码。它的任务是从设备把数据搬回来。
write： 核心成员。应用程序调用 write() 时执行。把数据扔给设备。
open： 入场券。每次应用程序打开设备文件（open("/dev/led")）时调用。通常在这里做初始化检查，或者把设备的私有数据挂载上去。
release： 离场手续。对应应用层的 close。虽然函数名叫 release，不是 close（因为 close 是应用层的行为，内核这里做的是释放资源）。当最后一个引用该文件的进程关闭它时，这个函数会被调用。

新内核新增的特性：

fop_flags_t：文件操作标志位，用于性能优化。这是一个新增的枚举类型，可以标记驱动支持的特性，比如是否支持缓冲区异步读写、是否支持 huge pages 等。
iopoll：用于 io_uring 的轮询操作，是高性能异步 I/O 的一部分。
uring_cmd / uring_cmd_iopoll：这是 io_uring 框架的一部分，提供了比传统 epoll 更高效的异步 I/O 机制。
__randomize_layout：这是结构体布局随机化属性，用于增强安全性，防止某些类型的安全攻击。

对于基本的字符设备驱动，你不需要实现所有这些新函数。核心的 open、read、write、release 保持不变，其他新的函数指针可以为 NULL。

设备号：驱动的「身份证」

每个字符设备都有一个唯一的身份标识，叫做设备号。

设备号是一个 32 位的整数，分为两部分：

主设备号（高 12 位）：标识驱动程序
次设备号（低 20 位）：标识使用该驱动的具体设备

你可以把主设备号理解成「公司代号」，次设备号理解成「员工编号」。比如所有硬盘的主设备号都是一样的，但每个硬盘有自己的次设备号。

在 /proc/devices 文件里，你可以看到当前系统中所有注册的设备号：

cat /proc/devices
Character devices:
  1 mem
  4 tty
  89 i2c
200 chrdevbase                    # 这是我们注册的设备

老内核的设备号管理

在老内核（4.1.15）中，设备号的管理相对简单：

/* 静态分配：手动指定主设备号为 200 */
#define MY_MAJOR 200
register_chrdev(MY_MAJOR, "mydev", &my_fops);

/* 动态分配：传 0 让内核自动分配 */
register_chrdev(0, "mydev", &my_fops);

这种方式的问题是：

静态分配容易冲突（别人可能也在用 200）
动态分配会占用整个主设备号下的 256 个次设备号，即使你只用 1 个

新内核的设备号管理

新内核（6.12.49 / 7.0.0-rc4）推荐使用更精细的管理方式：

dev_t dev_num;  /* 设备号变量 */

/* 动态分配：只申请 1 个设备号 */
alloc_chrdev_region(&dev_num, 0, 1, "mydev");

/* 如果需要知道分配到哪个号 */
printk("major=%d, minor=%d\n", MAJOR(dev_num), MINOR(dev_num));

这种方式的优势：

精确控制资源占用，只申请需要的设备号数量
避免浪费整个主设备号
更符合现代内核的资源管理理念

我们的第一个目标

看完了这些庞杂的概念，你可能会觉得压力山大——这么多函数、这么多数据结构，从哪里开始？

其实不用焦虑。我们的目标是：实现一个最小化的字符设备驱动。

我们不需要把上面每一个函数都填满，但我们会把整个框架搭起来。

你要记住的是：驱动开发的核心，就是填写 file_operations 这个结构体，然后把它注册到内核里去。

只要这一步通了，剩下的就是具体的业务逻辑——怎么操作寄存器，怎么处理中断，那些只是填充函数体里的代码罢了。

接下来，我们就从最基础的模块加载开始，让内核真正「认识」我们的代码。

内核版本的选择

在开始之前，你需要决定使用哪个内核版本来学习。

老内核（4.1.15）- 历史参考

这是 NXP i.MX 官方 SDK 的内核版本，在我们的教程中保留作为历史参考。

特点：

API 简单直接，一行代码就能注册字符设备
文档和参考资料比较多
适合维护老系统

缺点：

资源管理粗糙，容易浪费设备号
不包含现代内核的新特性
代码风格较旧

新内核（6.12.49 / 7.0.0-rc4）- 推荐学习

这是当前推荐学习的内核版本，包含最新的特性和优化。

特点：

API 设计更精细，资源管理更好
包含 io_uring、异步 I/O 等现代特性
代码风格更规范，安全性更高

选择建议：

如果你是新手：直接学新内核，老 API 已经过时了
如果你要维护老系统：参考老内核部分，了解老 API 的用法
如果你要开发新驱动：必须用新内核 API

嵌入式Linux驱动教程——字符设备驱动简介