2. Linux USB 子系统架构：三层模型详解
Linux USB 子系统采用经典的三层软件架构设计，将协议栈、硬件控制与设备功能实现解耦。这三层分别是：USB 核心层（USB Core）、主机控制器驱动（HCD） 以及 设备驱动层（Gadget/Function）。理解每一层的职责与交互关系，是掌握 USB 中断传输实时性的前提。
学习提示： 三层模型是 Linux USB 子系统的骨架。在实时通信场景中，中断传输的延迟抖动主要发生在 HCD 层与 Core 层的调度边界上，请重点关注层间接口与数据路径。
2.1 三层模型总体架构
下图展示了 Linux USB 子系统三层模型的核心组件及其数据流方向。左侧为主机侧（Host），右侧为设备侧（Device/Gadget），中间为 USB Core 层提供的统一抽象接口。
2.2 USB 核心层（USB Core）
USB Core 是 Linux USB 子系统的中枢神经，它向上为设备驱动提供统一的 API，向下通过 HCD 与硬件通信。Core 层不关心具体硬件实现，只负责协议层面的通用逻辑。
2.2.1 Core 层核心职责
| 职责模块 | 说明 | 中断传输相关性 |
|---|---|---|
| 设备枚举 | 检测设备插入/拔出，分配地址，读取描述符 | 低（枚举阶段使用控制传输） |
| URB 管理 | 创建、提交、取消、完成回调 URB | 高（中断传输依赖 URB 生命周期） |
| 带宽调度 | 管理帧/微帧内的传输时间槽 | 高（决定中断传输的周期与抖动） |
| 电源管理 | 挂起/唤醒、远程唤醒处理 | 中（唤醒延迟影响实时性） |
| 协议抽象 | 提供 usb_submit_urb()、usb_complete() 等接口 | 高（所有传输类型共用） |
2.2.2 URB 生命周期与中断传输
中断传输在 Core 层以 URB（USB Request Block） 为核心载体。一个典型的中断 URB 生命周期包含以下步骤：
- 分配 URB：调用
usb_alloc_urb()分配 URB 结构体，指定中断端点、传输方向、数据缓冲区。 - 填充 URB：设置
urb->interval（中断轮询间隔，单位：帧/微帧）、urb->complete（完成回调函数）。 - 提交 URB：调用
usb_submit_urb()，Core 层检查带宽并加入调度队列。 - 硬件传输：HCD 在每帧/微帧的调度时间点执行传输。
- 完成回调：传输完成后，HCD 调用 Core 层的完成处理，最终触发设备驱动的回调函数。
- 重新提交：中断传输通常需要持续轮询，驱动在回调中再次提交 URB。
实时性关键点： 中断 URB 的
interval 字段直接决定了轮询频率。在 USB 2.0 全速模式下，最小间隔为 1 帧（1 ms）；高速模式下最小间隔为 1 微帧（125 µs）。实时系统需要根据通信周期精确设置此值。
2.3 主机控制器驱动（HCD）
HCD 是直接与 USB 主机控制器硬件交互的软件层。不同的硬件规范对应不同的 HCD 实现：
| HCD 类型 | 对应规范 | 典型硬件 | 中断传输特性 |
|---|---|---|---|
| EHCI | USB 2.0 高速 | Intel ICH 系列 | 微帧调度，125 µs 精度 |
| xHCI | USB 3.x 超高速 | Intel/AMD 原生控制器 | 中断事件 TRB，支持流式传输 |
| OHCI | USB 1.1 全速/低速 | 非 Intel 平台（如 S3C2440） | 帧调度，1 ms 精度 |
| UHCI | USB 1.1 全速/低速 | Intel/PIIX4 等 | 帧调度，软件管理带宽 |
2.3.1 HCD 中断处理流程
HCD 层的中断处理是实时通信中最容易产生延迟抖动的环节。下图展示了从硬件中断触发到设备驱动回调的完整路径：
实时系统警告： 标准 Linux 内核中，HCD 的中断下半部使用 Tasklet（软中断上下文），其优先级低于硬件中断但高于普通进程。在实时性要求严格的场景（如工业以太网网关），建议使用 PREEMPT_RT 内核将 Tasklet 转换为可抢占的线程，或使用 threaded IRQ 减少优先级反转。
2.4 设备驱动层（Gadget/Function）
在设备侧（Gadget 模式），Linux USB 子系统提供了 Gadget API 框架，用于实现各种 USB 设备功能。Function 驱动是实际实现设备逻辑的模块，例如 UVC（摄像头）、UAC（音频）、RNDIS（网络）等。
2.4.1 Gadget 框架层次
| 层次 | 组件 | 职责 |
|---|---|---|
| UDC 驱动 | USB Device Controller 驱动 | 直接操作硬件寄存器，处理端点中断 |
| Gadget 层 | usb_gadget_driver | 管理配置、接口、端点分配 |
| Function 层 | usb_function | 实现具体设备功能，处理中断传输请求 |
| ConfigFS / Legacy | 用户空间配置接口 | 动态组合 Function，绑定端点 |
2.4.2 中断传输在 Function 中的实现
在 Gadget 侧，中断传输通过 usb_ep_queue() 接口提交请求。Function 驱动需要：
- 在绑定阶段申请中断端点（
usb_ep_autoconfig()）。 - 分配请求结构体（
usb_ep_alloc_request()）。 - 填充数据缓冲区并调用
usb_ep_queue()提交。 - 在完成回调中处理数据并重新提交（持续轮询模式）。
中断传输 vs 批量传输： 在 Gadget 侧，中断传输保证每帧/微帧至少有一次轮询机会，而批量传输只在带宽空闲时执行。对于实时通信，中断传输的确定性远高于批量传输。
2.5 三层模型交互总结
下表从实时通信的角度，总结三层模型中各层的关键关注点：
| 层次 | 关键组件 | 实时性关注点 | 优化方向 |
|---|---|---|---|
| USB Core | URB 调度器、带宽管理 | URB 提交延迟、调度队列长度 | 减少 URB 分配/释放开销，使用 URB 池 |
| HCD | 中断处理、DMA 管理 | ISR 执行时间、Tasklet 调度延迟 | 使用 threaded IRQ、PREEMPT_RT |
| Gadget/Function | 端点管理、请求队列 | 请求提交/完成回调延迟 | 使用双缓冲、减少上下文切换 |
实践建议： 在编写中断传输的实时应用时，建议在 Function 驱动中预先分配多个请求（request pool），避免在中断路径中动态分配内存。同时，将完成回调设计为无锁或使用 RCU 机制，减少内核抢占点。