Linux为何需要char_device_struct与cdev两种结构体表示字符设备？

核心原因在于职责分离、历史演进以及灵活性需求，具体拆解如下：

1. 历史演进的产物 #

早期Linux字符设备驱动用register_chrdev()接口一次性完成设备号注册和驱动操作绑定，但这种“一站式”方案无法适配复杂场景——比如没法细粒度管理设备号区间，也不能灵活绑定多个设备实例到同一主设备号下。

后来内核将流程拆分为两步：用register_chrdev_region()注册设备号（由char_device_struct负责管理），再用cdev_add()绑定具体设备操作（对应cdev结构体）。这种拆分是为了适配更复杂的驱动场景，并非设计之初刻意拆分。

2. 职责单一，降低耦合 #

• char_device_struct只做设备号元数据管理：它就是系统里设备号的“台账”，只跟踪哪些设备号区间已被占用，避免分配冲突，和设备操作完全无关。
• cdev是设备操作的实际载体：它绑定了file_operations和对应设备号范围，是用户空间发起IO请求时的处理入口。

拆分后两个模块逻辑完全独立：调整设备号分配规则（比如修改哈希链大小）不用动cdev的代码；新增设备操作特性（比如支持异步IO）也不会影响设备号管理逻辑，极大降低了代码耦合度。

3. 适配灵活的驱动场景 #

这种拆分能满足多种复杂驱动需求：

• 多设备实例共享设备号区间：比如一个驱动管10个同类型传感器，每个传感器对应一个cdev实例，它们可以共享同一个主设备号，只用不同次设备号区分。这时只需要注册一次设备号区间，再逐个添加cdev即可。
• 设备号与驱动操作解绑：卸载单个设备实例时，只需要调用cdev_del()移除对应的cdev，不用释放整个设备号区间（只要还有其他设备在使用该区间）。
• 延迟绑定驱动操作：可以先申请设备号区间“占坑”，之后再根据硬件初始化情况动态绑定cdev，这种方式在热插拔设备场景里特别实用。

内容的提问来源于stack exchange，提问作者muqu