USB/IP 架构与实现总览

1. 目标

USB/IP不转发设备文件操作，而是在内核USB层转发URB。客户端看到正常USB设备并加载原有class driver；服务端把URB提交给真实HCD或虚拟UDC。

客户端                                             服务端
class driver                                       真实USB设备
    │ URB                                               │
usbcore                                            本地HCD
    │                                                   │
vhci-hcd ── CMD_SUBMIT/UNLINK ── TCP ── usbip-host(stub)
         ◄─ RET_SUBMIT/UNLINK ─────────

VUDC路径把服务端右侧替换为Gadget：

远端vhci-hcd ← TCP → usbip-vudc ← UDC Core ← composite/configfs function

2. 四个内核模块

模块	配置	角色
usbip-core	USBIP_CORE	PDU、socket辅助、事件处理、调试
usbip-host	USBIP_HOST	绑定整台物理USB device并导出
vhci-hcd	USBIP_VHCI_HCD	客户端虚拟USB2/USB3 HCD
usbip-vudc	USBIP_VUDC	服务端虚拟UDC，导出软件Gadget

usbip-host和vhci-hcd依赖USB；VUDC依赖USB_GADGET。三者都依赖USBIP_CORE和网络栈。

3. 控制面与数据面

控制面位于用户态：

1. usbip bind把busid加入stub匹配表并绑定设备；
2. usbipd监听TCP 3240；
3. client执行usbip attach，完成DEVLIST/IMPORT握手；
4. 用户态把已连接socket fd写入内核sysfs；
5. 内核接管socket，启动RX/TX线程。

数据面随后完全位于内核：

URB -> USB/IP PDU -> kernel socket -> PDU -> URB

用户态守护进程不逐包转发URB payload。

4. 设备模型位置

• Stub注册usb_device_driver，以整设备粒度接管全部interface；
• VHCI注册hc_driver，向USB Core提供软件Root Hub；
• VUDC注册usb_gadget，向UDC Core提供虚拟endpoint；
• 用户态通过sysfs传递socket和端口参数，不直接操作内核链表。

5. 协议阶段

连接先使用用户态操作协议完成设备发现和导入；成功后同一TCP连接切换为内核URB协议：

• USBIP_CMD_SUBMIT / USBIP_RET_SUBMIT；
• USBIP_CMD_UNLINK / USBIP_RET_UNLINK。

所有32-bit协议字段按网络大端传输，bulk/control/interrupt/isochronous都复用同一基本头。

6. 与RK3588硬件关系

USB/IP不是RK3588 DWC3/xHCI/EHCI的专用驱动。作为服务端导出物理设备时，它位于任意本地USB Host controller之上；作为客户端时，远端设备挂在VHCI软件总线上，不经过RK3588物理USB PHY。

因此RK3588差异主要是：

• 真实设备插在哪个板级Host端口；
• 网络链路吞吐、CPU和内存带宽；
• 产品内核是否启用USB/IP；
• 安全策略是否允许远端注入USB设备。

7. 关键限制

• TCP带来队头阻塞，无法提供USB帧级实时性；
• 网络断开等价于USB设备突然拔出；
• 协议本身不提供可靠的身份认证或机密性；
• 远端设备描述符和数据进入本地USB/class parser，信任边界显著扩大；
• Hub不能按普通终端设备方式导出；
• VHCI suspend/resume和frame number实现有限，不应按真实HCD能力推断。