4、字符设备驱动核心概念：主设备号与次设备号、设备文件、file_operations结构体、cdev注册流程

字符设备驱动是嵌入式Linux驱动开发的基石。无论是GPIO控制、UART串口、I2C传感器，还是SPI Flash，绝大多数外设驱动在Linux内核中都归属于字符设备范畴。理解字符设备驱动的核心概念，意味着要打通从“内核驱动代码”到“用户空间应用程序”的完整链路：设备号用于在内核中唯一标识设备，设备文件是用户空间访问驱动的入口，file_operations结构体是驱动能力的具体实现，而cdev注册流程则是将前三者绑定并告知内核的工程化步骤。本章将围绕这四个核心概念展开，帮助读者建立字符设备驱动的整体认知框架。

4.1 主设备号与次设备号：设备在内核中的“身份证”

4.1.1 核心原理：设备号的数据结构与分配机制

在Linux内核中，每个字符设备或块设备都拥有一个唯一的设备编号，类型为dev_t，本质上是一个32位无符号整数。内核将dev_t划分为两部分：高12位表示主设备号（major number），低20位表示次设备号（minor number）。主设备号用于标识设备对应的驱动程序，即“哪类设备”；次设备号用于标识由同一驱动程序管理的具体设备实例，即“第几个设备”。例如，一个USB转串口芯片CP2102，其主设备号可能为188，而系统中有多个USB串口时，次设备号依次为0、1、2……

设备号的分配有两种方式：静态分配和动态分配。静态分配是指驱动开发者在内核源码的Documentation/admin-guide/devices.txt中查找尚未被占用的主设备号，并在驱动代码中直接指定。这种方式简单直接，但容易冲突，且需要维护全局列表。动态分配则调用alloc_chrdev_region()函数，由内核自动分配一个未使用的主设备号，通过参数返回。动态分配是驱动开发中的推荐做法，尤其在开源驱动和模块化驱动中广泛使用。

4.1.2 判断方法：查看设备号的常用命令

在实际开发中，我们经常需要查看系统中设备号的分配情况。以下命令是嵌入式开发者的“标配工具”：

# 查看已加载字符设备的主次设备号
cat /proc/devices

# 查看设备文件的详细信息（含主次设备号）
ls -l /dev/ttyS0 /dev/ttyUSB0

# 使用stat命令查看设备号
stat -c "主设备号: %t  次设备号: %T" /dev/ttyS0

/proc/devices文件列出了内核中已注册的字符设备和块设备的主设备号及名称。当驱动通过cdev_add()成功注册后，其主设备号和设备名会出现在该文件中。而ls -l输出中，设备文件权限位后的两个数字分别代表主设备号和次设备号（以十进制显示）。

4.1.3 案例拆解：动态分配设备号的典型代码

以下代码展示了在驱动初始化函数中动态申请设备号的过程：

#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/device.h>

#define DEVICE_NAME "my_led"
static dev_t dev_num;          // 用于存放申请到的设备号
static struct cdev my_cdev;

static int __init my_driver_init(void)
{
    int ret;
    // 动态申请设备号：第一个参数为输出参数，返回分配到的设备号
    // 第二个参数为次设备号起始值，第三个参数为连续次设备号数量
    // 第四个参数为设备名称（出现在/proc/devices中）
    ret = alloc_chrdev_region(&dev_num, 0, 1, DEVICE_NAME);
    if (ret < 0) {
        printk(KERN_ERR "Failed to alloc chrdev region\n");
        return ret;
    }
    printk(KERN_INFO "Allocated major=%d minor=%d\n", 
           MAJOR(dev_num), MINOR(dev_num));
    // 后续的cdev_init和cdev_add操作...
    return 0;
}

在嵌入式Linux开发板上，驱动加载后通过dmesg可以看到内核打印的主设备号。例如输出Allocated major=240 minor=0，说明内核动态分配了主设备号240。此时/proc/devices中也会出现一行240 my_led。

4.2 设备文件：用户空间访问驱动的“门户”

4.2.1 核心原理：设备文件与VFS的桥接作用

设备文件（device file）是Linux文件系统中的一个特殊文件类型，它不占用磁盘数据块，而是作为用户空间与内核驱动之间的桥梁。当应用程序对设备文件执行open()、read()、write()等系统调用时，虚拟文件系统（VFS）会根据设备文件中的主设备号找到对应的驱动程序，并调用该驱动注册的file_operations中的相应函数。设备文件通常位于/dev目录下，其类型标识为c（字符设备）或b（块设备）。

设备文件的创建有两种方式：手动创建和自动创建。手动创建使用mknod命令，需要指定设备类型、主设备号和次设备号。自动创建则依赖udev（桌面Linux）或mdev（BusyBox嵌入式环境）等设备管理器。当驱动调用device_create()函数时，内核会向用户空间发送uevent，设备管理器监听该事件后，根据预置规则在/dev下动态创建设备文件。

4.2.2 操作流程：从手动到自动的设备文件管理

在驱动代码中，自动创建设备文件的标准流程是：先创建struct class，再调用device_create()。示例代码如下：

static struct class *my_class;

// 在驱动初始化函数中
my_class = class_create(THIS_MODULE, "my_class");
if (IS_ERR(my_class)) {
    unregister_chrdev_region(dev_num, 1);
    return PTR_ERR(my_class);
}

// 创建设备文件 /dev/my_led
device_create(my_class, NULL, dev_num, NULL, "my_led");

当驱动卸载时，需要反向操作：先device_destroy()删除设备文件，再class_destroy()删除类，最后unregister_chrdev_region()释放设备号。

4.3 file_operations结构体：驱动能力的“函数指针表”

4.3.1 核心原理：从系统调用到驱动函数的映射

struct file_operations是Linux驱动开发中最核心的数据结构之一。它定义在linux/fs.h中，包含了一系列函数指针，每个指针对应一个系统调用接口。当用户空间程序调用open()时，VFS最终会调用驱动中file_operations的.open成员；调用read()时，对应.read成员。驱动开发者通过实现这些函数指针，将设备的具体操作逻辑（如读写寄存器、控制GPIO、收发数据）封装起来。

常用的file_operations成员包括：

• .owner：通常设置为THIS_MODULE，用于模块引用计数管理。
• .open：打开设备时调用，常用于初始化硬件、增加引用计数。
• .release：关闭设备时调用，用于释放资源、减少引用计数。
• .read：从设备读取数据，函数原型为ssize_t (*read)(struct file *, char __user *, size_t, loff_t *)。
• .write：向设备写入数据，函数原型为ssize_t (*write)(struct file *, const char __user *, size_t, loff_t *)。
• .unlocked_ioctl：设备控制命令接口，用于传递非读写类的控制指令。

4.3.2 判断方法：如何确定需要实现哪些函数

并非所有函数指针都必须实现。如果某个函数指针为NULL，对应的系统调用将返回-EINVAL或-ENOTTY。判断需要实现哪些函数，应遵循以下原则：

1. 基础必备：.owner必须设置；.open和.release通常实现，用于资源管理。
2. 按设备类型：输出类设备（如LED、LCD）必须实现.write；输入类设备（如按键、触摸屏）必须实现.read；双向设备（如UART）两者都要实现。
3. 控制类操作：如果设备需要配置参数（如设置波特率、调节音量），必须实现.unlocked_ioctl。

4.3.3 案例拆解：一个LED驱动的file_operations实现

以下是一个简单LED字符驱动的file_operations实现，展示了open、write和release的典型写法：

static int led_open(struct inode *inode, struct file *filp)
{
    // 初始化GPIO，设置为输出模式
    gpio_direction_output(LED_PIN, 0);
    printk(KERN_INFO "LED device opened\n");
    return 0;
}

static ssize_t led_write(struct file *filp, const char __user *buf,
                         size_t count, loff_t *ppos)
{
    char kbuf[2];
    if (count < 1)
        return -EINVAL;
    // 从用户空间拷贝数据到内核空间
    if (copy_from_user(kbuf, buf, 1))
        return -EFAULT;
    // 根据写入值控制LED亮灭
    if (kbuf[0] == '1')
        gpio_set_value(LED_PIN, 1);   // 点亮
    else if (kbuf[0] == '0')
        gpio_set_value(LED_PIN, 0);   // 熄灭
    else
        return -EINVAL;
    return count;
}

static int led_release(struct inode *inode, struct file *filp)
{
    gpio_set_value(LED_PIN, 0);  // 关闭LED
    printk(KERN_INFO "LED device closed\n");
    return 0;
}

static struct file_operations led_fops = {
    .owner   = THIS_MODULE,
    .open    = led_open,
    .write   = led_write,
    .release = led_release,
};

用户空间测试程序只需执行echo 1 > /dev/my_led即可点亮LED，执行echo 0 > /dev/my_led熄灭LED。这里的关键点是copy_from_user()函数，它负责安全地将用户空间缓冲区数据拷贝到内核空间，防止用户传入非法指针导致内核崩溃。

4.4 cdev注册流程：将驱动“挂载”到内核

4.4.1 核心原理：cdev结构体与内核设备模型

struct cdev是内核中表示字符设备的核心结构体。它封装了设备号、file_operations指针以及内核设备模型中的链表节点。驱动开发者需要完成三个关键步骤：分配设备号、初始化cdev、将cdev添加到内核。只有完成cdev_add()后，内核才真正“认识”这个设备，用户空间才能通过设备文件访问它。

完整的cdev注册流程如下：

1. 分配设备号：调用alloc_chrdev_region()（动态）或register_chrdev_region()（静态）。
2. 初始化cdev：调用cdev_init()，将struct cdev与file_operations绑定。
3. 添加cdev：调用cdev_add()，将设备加入内核的字符设备列表。
4. 创建设备文件：通过class_create()和device_create()在/dev下生成设备节点。

4.4.2 操作流程：标准注册代码模板

以下是一个完整的字符设备驱动初始化与退出模板，涵盖了cdev注册的全部步骤：

#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/device.h>

#define DEVICE_NAME "demo_dev"
#define CLASS_NAME  "demo_class"

static dev_t dev_num;
static struct cdev demo_cdev;
static struct class *demo_class;
static struct device *demo_device;

static int __init demo_init(void)
{
    int ret;

    // 步骤1: 动态分配设备号
    ret = alloc_chrdev_region(&dev_num, 0, 1, DEVICE_NAME);
    if (ret < 0) {
        pr_err("Failed to allocate device number\n");
        return ret;
    }
    pr_info("Major: %d, Minor: %d\n", MAJOR(dev_num), MINOR(dev_num));

    // 步骤2: 初始化cdev并绑定file_operations
    cdev_init(&demo_cdev, &demo_fops);
    demo_cdev.owner = THIS_MODULE;

    // 步骤3: 将cdev添加到内核
    ret = cdev_add(&demo_cdev, dev_num, 1);
    if (ret < 0) {
        pr_err("Failed to add cdev\n");
        goto err_unregister;
    }

    // 步骤4: 创建设备类
    demo_class = class_create(THIS_MODULE, CLASS_NAME);
    if (IS_ERR(demo_class)) {
        pr_err("Failed to create class\n");
        ret = PTR_ERR(demo_class);
        goto err_cdev_del;
    }

    // 步骤5: 创建设备文件 /dev/demo_dev
    demo_device = device_create(demo_class, NULL, dev_num, NULL, DEVICE_NAME);
    if (IS_ERR(demo_device)) {
        pr_err("Failed to create device\n");
        ret = PTR_ERR(demo_device);
        goto err_class_destroy;
    }

    pr_info("Demo driver initialized successfully\n");
    return 0;

err_class_destroy:
    class_destroy(demo_class);
err_cdev_del:
    cdev_del(&demo_cdev);
err_unregister:
    unregister_chrdev_region(dev_num, 1);
    return ret;
}

static void __exit demo_exit(void)
{
    device_destroy(demo_class, dev_num);
    class_destroy(demo_class);
    cdev_del(&demo_cdev);
    unregister_chrdev_region(dev_num, 1);
    pr_info("Demo driver exited\n");
}

module_init(demo_init);
module_exit(demo_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Embedded Engineer");

4.4.3 常见误区与排障复盘

在cdev注册过程中，初学者常犯以下错误：

4.5 综合案例：从零编写一个完整的字符设备驱动

为了将本章四个核心概念串联起来，我们设计一个完整的实战案例：基于SysFS的虚拟传感器驱动。该驱动模拟一个温度传感器，用户空间通过读写设备文件获取或设置温度值。

4.5.1 需求分析与设计

项目背景：某嵌入式网关设备需要读取环境温度，硬件上使用I2C接口的温度传感器（如LM75）。在驱动开发初期，硬件尚未就绪，需要先编写一个虚拟驱动用于应用层联调。约束条件：驱动必须支持动态设备号分配、自动创建设备文件、通过read()读取温度、通过write()设置温度偏移量。

4.5.2 驱动实现关键代码

#define TEMP_BASE 25   // 基础温度25°C
static int temp_offset = 0;  // 温度偏移量

static ssize_t temp_read(struct file *filp, char __user *buf,
                         size_t count, loff_t *ppos)
{
    char temp_str[16];
    int len;
    int temp = TEMP_BASE + temp_offset;
    
    len = snprintf(temp_str, sizeof(temp_str), "%d\n", temp);
    if (*ppos >= len)
        return 0;
    if (copy_to_user(buf, temp_str, len))
        return -EFAULT;
    *ppos = len;
    return len;
}

static ssize_t temp_write(struct file *filp, const char __user *buf,
                          size_t count, loff_t *ppos)
{
    char kbuf[16];
    int value;
    
    if (count >= sizeof(kbuf))
        return -EINVAL;
    if (copy_from_user(kbuf, buf, count))
        return -EFAULT;
    kbuf[count] = '\0';
    
    if (kstrtoint(kbuf, 10, &value))
        return -EINVAL;
    temp_offset = value;
    return count;
}

static struct file_operations temp_fops = {
    .owner   = THIS_MODULE,
    .read    = temp_read,
    .write   = temp_write,
};

4.5.3 测试与验证

驱动加载后，执行以下命令验证功能：

# 加载驱动
insmod temp_driver.ko

# 查看设备号
cat /proc/devices | grep temp

# 读取温度
cat /dev/temp_sensor
# 输出: 25

# 设置温度偏移
echo 5 > /dev/temp_sensor

# 再次读取
cat /dev/temp_sensor
# 输出: 30

# 卸载驱动
rmmod temp_driver

测试结果符合预期。该案例完整展示了设备号分配、设备文件创建、file_operations实现和cdev注册的全流程。在实际项目中，只需将temp_read中的模拟数据替换为真实读取I2C传感器的代码，即可完成从虚拟驱动到真实驱动的迁移。