linux驱动开发之字符设备与总线设备驱动模型的区别与联系

Linux驱动开发核心概念解析

1. 字符设备（Character Device）

定义与特点：
- 以字节流形式进行数据交换，适用于顺序访问的设备（如键盘、鼠标、串口）。
- 用户空间通过设备文件（如/dev/xxx）访问，依赖主/次设备号标识驱动与实例。
驱动开发关键步骤：
1. 实现文件操作接口：通过file_operations结构体定义open、read、write、release等函数。
2. 注册设备号：
  - 动态分配：alloc_chrdev_region获取主设备号。
  - 静态注册：register_chrdev_region（需确保未被占用）。
3. 创建设备：
  - 初始化cdev结构体（cdev_init），关联file_operations。
  - 添加设备到内核：cdev_add。
4. 生成设备节点：
  - 自动创建：通过class_create和device_create，触发udev生成/dev/xxx。
  - 手动创建：mknod命令。

示例代码片段：

复制

static struct file_operations fops = {
    .owner = THIS_MODULE,
    .open = my_open,
    .read = my_read,
    .write = my_write,
    .release = my_release,
};

static int __init my_init(void) {
    alloc_chrdev_region(&dev_num, 0, 1, "mydev");
    cdev_init(&my_cdev, &fops);
    cdev_add(&my_cdev, dev_num, 1);
    my_class = class_create(THIS_MODULE, "myclass");
    device_create(my_class, NULL, dev_num, NULL, "mydev");
    return 0;
}

2. 总线设备驱动模型（Bus-Device-Driver Model）

核心组件：
- 总线（Bus）：管理设备与驱动的匹配（如PCI、USB、虚拟总线如platform）。
- 设备（Device）：描述硬件信息（资源、中断等），可通过设备树（Device Tree）动态配置。
- 驱动（Driver）：实现设备操作逻辑，包含初始化、资源获取（如probe）和释放（remove）。
工作流程：
1. 设备注册：向总线注册设备信息（如platform_device_register）。
2. 驱动注册：向总线注册驱动（如platform_driver_register），提供probe和remove函数。
3. 匹配过程：总线根据设备ID表或设备树的compatible属性匹配设备与驱动。
4. 初始化与销毁：匹配成功时调用probe，失败或卸载时调用remove。
设备树（Device Tree）的作用：
- 替代硬编码，描述硬件资源（如寄存器地址、中断号）。
- 驱动通过of_match_table匹配设备树节点，使用of_系列API获取资源（如of_get_property）。

Platform总线示例：

复制

// 设备树节点
mydevice {
    compatible = "mycompany,mydevice";
    reg = <0x10000000 0x1000>;
    interrupts = <0 1>;
};

// 驱动匹配与初始化
static const struct of_device_id my_of_ids[] = {
    { .compatible = "mycompany,mydevice" },
    { }
};

static int my_probe(struct platform_device *pdev) {
    struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    // 初始化字符设备...
    return 0;
}

static struct platform_driver my_driver = {
    .probe = my_probe,
    .remove = my_remove,
    .driver = {
        .name = "mydrv",
        .of_match_table = my_of_ids,
    },
};
module_platform_driver(my_driver);

3. 字符设备与总线模型的整合

场景：基于总线（如I2C）的字符设备（如传感器）。
1. 总线驱动：处理总线协议（如I2C读写），在probe中注册字符设备。
2. 字符设备驱动：通过file_operations暴露用户接口，调用总线驱动提供的底层操作。
优势：
- 解耦硬件与接口：总线驱动处理硬件细节，字符设备驱动处理用户交互。
- 复用性：同一总线驱动支持多种设备，同一字符设备驱动适配不同总线。

4. 关键工具与调试

sysfs：在/sys/bus、/sys/devices查看设备层次结构。
调试技术：printk、dmesg、devtmpfs自动创建设备节点。
动态加载：insmod/rmmod加载驱动模块。

总结

字符设备：关注用户空间接口，实现字节流操作。
总线模型：分离设备与驱动，提升灵活性和可维护性。
设备树：动态配置硬件资源，增强代码可移植性。

学习建议：通过实际项目（如LED控制、传感器驱动）结合代码实践，深入理解设备树配置、总线匹配机制及字符设备接口的实现。

首先，字符设备，我记得它们是用来处理按字节流进行数据交换的设备，比如键盘、鼠标、串口这些。和块设备不同，块设备是按块来操作的，比如硬盘。字符设备驱动需要实现哪些东西呢？应该是要实现file_operations结构体里的那些函数，比如open、read、write、release之类的。用户空间通过设备文件来访问这些设备，比如/dev下面的那些节点，主设备号用来标识驱动，次设备号区分不同实例。那创建字符设备的时候，是不是要用register_chrdev或者更新的方法，比如alloc_chrdev_region加上cdev_init和cdev_add？可能还有设备类相关的操作，比如class_create和device_create，这样udev会自动创建设备节点。

然后是总线设备驱动模型，这部分我有点模糊。总线模型应该是指设备如何连接到总线，比如PCI、USB、I2C这些总线类型。总线设备驱动模型分为总线、设备、驱动三个部分，对吧？总线负责匹配设备和驱动，当设备插入时，总线会寻找对应的驱动，或者驱动加载时寻找对应的设备。这样的话，设备和驱动是分开注册的，通过总线进行匹配。设备结构体platform_device，驱动结构体platform_driver，可能属于平台设备，不依赖于物理总线的那种虚拟总线？比如SOC上的各种控制器。那platform_driver里面应该有probe和remove函数，当设备匹配时，probe会被调用，进行初始化，remove则是清理资源。匹配的依据是什么呢？可能是通过名字，或者是设备树中的兼容性字符串。

设备树在总线模型中起什么作用呢？设备树用来描述硬件配置，代替原来的硬编码。驱动可以通过设备树获取资源，比如内存地址、中断号，而不需要在内核中写死。这样同一个驱动可以支持不同的硬件配置，只要设备树描述正确。比如，platform设备可能从设备树中获取资源，驱动使用of_match_table来匹配设备树中的节点。

那总线模型中的匹配过程是怎样的呢？当设备注册时，总线会检查是否有对应的驱动已经注册，如果有的话，调用驱动的probe函数。同样，当驱动注册时，总线会检查是否有对应的设备存在，有的话也会调用probe。匹配通常基于设备ID表或者设备树中的compatible属性。对于platform设备，可能用platform_device_id或者设备树中的compatible字符串来匹配。

字符设备和总线模型之间的关系是什么呢？比如，一个字符设备驱动可能基于某个总线模型。例如，一个I2C设备驱动，属于总线模型中的驱动部分，同时它提供的设备可能作为字符设备被用户空间访问。这时候，驱动需要同时处理总线的匹配和字符设备的操作函数。

可能还有一些例子，比如编写一个简单的字符设备驱动，需要注册字符设备，实现file_operations。而如果是总线模型的设备，比如platform驱动，则需要注册platform_driver，并在probe函数中注册字符设备，这样当platform设备匹配时，probe被调用，进而创建设备节点。

还有，sysfs的作用是什么？总线、设备、驱动都会在sysfs中有对应的条目，用户空间可以通过sysfs查看设备和驱动的信息，进行一些配置或者状态查询。例如，/sys/bus/下面有各种总线的目录，里面包含了注册的设备和驱动。

我是不是漏掉了什么重要的概念？比如，设备模型中的kobject、kset、ktype这些底层结构？可能总线模型是基于kobject的sysfs表示的，每个设备、驱动都是kobject的子对象，通过层次结构组织起来。这样sysfs就能展示出设备树的层次结构。

另外，模块的加载和卸载过程，字符设备驱动模块在加载时需要注册设备，卸载时注销。而对于总线模型中的驱动模块，加载时会注册驱动，卸载时注销驱动，并调用remove函数释放资源。

还有设备号的申请，动态分配还是静态注册？现在更推荐动态分配，使用alloc_chrdev_region，这样可以避免冲突。静态的话需要知道哪些主设备号未被占用，可能不太方便。

总结一下，字符设备驱动关注的是用户空间的接口，通过file_operations提供操作函数。而总线设备驱动模型关注的是设备与驱动的匹配和管理，利用总线作为中介，分离设备和驱动的代码，提高可重用性和可维护性。设备树在此模型中用于硬件描述，使得驱动代码更独立于具体硬件配置。

现在可能存在的疑问点：总线模型中platform总线和实际物理总线（如I2C）的区别；设备树如何具体在驱动中被解析和使用；probe函数的具体作用和调用时机；sysfs与设备模型的关系；以及如何将字符设备驱动整合到总线模型中。需要进一步查阅资料或例子来验证这些理解是否正确。