2. USB Gadget框架总览：Linux内核中的Gadget驱动栈

USB Gadget 驱动栈是 Linux 内核中用于实现设备端（Device Side）USB 功能的核心软件架构。它允许嵌入式设备（如开发板、手机、IoT 网关）模拟成各种 USB 外设，例如虚拟串口（CDC ACM）、以太网卡（RNDIS/EEM）、大容量存储（Mass Storage）、MIDI 设备或自定义 HID 设备。理解整个驱动栈的分层结构是面试中考察候选人对 USB 子系统宏观认知的关键。

2.1 Gadget驱动栈四层架构

Linux 内核的 USB Gadget 驱动栈从下到上分为四个主要层次：UDC 硬件层、UDC Core 核心层、Gadget 功能层 和 用户态配置层。每一层都通过标准的内核 API 进行解耦，使得硬件驱动、功能实现和配置方式可以独立开发和组合。

2.2 各层核心职责与关键数据结构

面试中，面试官会深入考察每一层的数据结构关系和回调函数。下表总结了各层的核心结构体、主要操作函数以及典型实现文件。

2.3 UDC Core：承上启下的核心枢纽

UDC Core（drivers/usb/gadget/udc-core.c）是整个 Gadget 框架的"交通警察"。它不直接操作硬件，而是提供一组标准 API，使得上层的功能驱动无需关心底层是 DWC3 还是 Chipidea。其核心工作流程如下：

1. UDC 驱动注册： 底层 UDC 控制器驱动通过 usb_add_gadget() 将 struct usb_gadget 注册到 UDC Core 维护的链表 udc_list 中。
2. Gadget 驱动注册： 上层功能组合驱动（如 g_serial.ko）通过 usb_gadget_probe_driver() 注册 struct usb_gadget_driver。
3. 绑定过程： UDC Core 遍历 udc_list，找到可用的 UDC 实例，调用 gadget_driver->bind() 回调，完成功能驱动与硬件控制器的绑定。
4. 事件转发： 当 UDC 硬件产生中断（如 SETUP 包到达、传输完成），UDC 驱动调用 UDC Core 提供的 usb_gadget_giveback_request() 等函数，将事件向上传递给功能驱动。

2.4 ConfigFS 与 FunctionFS：两种用户态配置路径

在较新的内核版本中（3.11+），ConfigFS 已成为配置 USB Gadget 的首选方式，而 FunctionFS 则提供了更灵活的用户态功能实现。面试官常会对比这两种机制，考察候选人对用户态与内核态交互的理解。

2.4.1 ConfigFS：基于 configfs 的静态配置

ConfigFS 将 USB Gadget 的配置过程映射为文件系统的目录和文件操作。用户通过 mkdir、rmdir 和 echo 命令即可完成 Gadget 的创建、功能绑定和启用，无需编写内核模块。

# 创建一个 Gadget 实例
$ mkdir /sys/kernel/config/usb_gadget/g1
$ cd /sys/kernel/config/usb_gadget/g1

# 设置 VID/PID
$ echo 0x1d6b > idVendor
$ echo 0x0104 > idProduct

# 创建配置（每个配置对应一个 USB 配置描述符）
$ mkdir configs/c.1
$ mkdir configs/c.1/strings/0x409
$ echo "Config 1: ECM" > configs/c.1/strings/0x409/configuration

# 创建功能实例并绑定到配置
$ mkdir functions/ecm.usb0
$ ln -s functions/ecm.usb0 configs/c.1

# 绑定到 UDC 控制器（启用 Gadget）
$ echo musb-hdrc.0 > UDC

2.4.2 FunctionFS：用户态实现 USB 功能

FunctionFS 允许用户态应用程序直接实现 USB 功能逻辑，而无需编写内核驱动。它通过 /dev/usb-ffs/ep0 和 /dev/usb-ffs/epN 文件接口与内核通信。

// 用户态程序使用 FunctionFS 的典型流程
int ep0_fd = open("/dev/usb-ffs/ep0", O_RDWR);

// 1. 写入描述符
write(ep0_fd, descriptors_buf, descriptors_len);

// 2. 写入字符串描述符
write(ep0_fd, strings_buf, strings_len);

// 3. 启动功能
write(ep0_fd, "\0", 1);  // 发送空字符串表示启动

// 4. 打开端点文件进行数据传输
int ep1_fd = open("/dev/usb-ffs/ep1", O_RDWR);
read(ep1_fd, data_buf, size);  // 接收主机数据
write(ep1_fd, data_buf, size); // 发送数据到主机

2.5 各层之间的数据流与接口关系

理解数据在 Gadget 栈中的流动方向，是回答"USB 请求如何从主机到达用户态应用"这类问题的关键。下面用表格总结典型的数据上行（主机→设备）路径：

2.6 面试高频追问与避坑指南

在面试中，面试官可能会基于上述框架提出以下追问，建议提前准备：

• 追问1： "ConfigFS 和 FunctionFS 可以同时使用吗？"
  答案： 可以。ConfigFS 用于配置整体 Gadget 结构（VID/PID、配置、功能绑定），而 FunctionFS 可以作为其中一个功能实例被绑定到配置中。例如，可以在 ConfigFS 中创建 functions/ffs.usb0，然后通过 FunctionFS 用户态程序实现自定义功能。
• 追问2： "UDC Core 中的 usb_udc 和 usb_gadget 有什么区别？"
  答案： usb_udc 是 UDC Core 内部用于管理 UDC 设备的结构体，包含 struct list_head 链表节点和 struct device；usb_gadget 是更底层的硬件抽象，包含端点列表、操作函数指针等。每个 usb_udc 包含一个 usb_gadget 指针。
• 追问3： "如果 UDC 硬件不支持某个端点类型（如 ISOCHRONOUS），Gadget 框架如何处理？"
  答案： 在 usb_gadget_probe_driver() 后的 bind() 回调中，功能驱动会遍历 gadget->ep_list 查找可用端点。如果找不到匹配的端点类型，bind() 返回 -ENODEV，Gadget 驱动注册失败。这是硬件能力与功能需求之间的契约检查。