我给你捋Linux 5.x 官方标准蓝牙架构和 Wi-Fi 架构高度对称你看完会发现蓝牙和 Wi-Fi 在 Linux 里设计几乎一模一样。蓝牙架构全程从硬件 → 驱动 → 内核 → 用户态一层一层讲透。一、一句话总架构和 Wi-Fi 对照记层次Wi-Fi 对应蓝牙对应硬件Wi-Fi 芯片BT 芯片内核子系统cfg80211 mac80211bluetooth (BT Core) hci用户态接口nl80211 (netlink)mgmt (HCI Management)命令行工具iwbluetoothctl连接守护进程wpa_supplicantbluetoothd蓝牙整体分层从下到上【1】蓝牙硬件芯片RF / HCI ↓ 【2】HCI 驱动 内核蓝牙子系统BT Core ↓ 【3】用户态守护进程bluetoothdBlueZ ↓ 【4】命令行 / 应用bluetoothctl / 手机APP / 音箱APP二、每层详细拆解从下到上【1】蓝牙硬件芯片射频 RF 基带标准HCIHost Controller Interface负责广播、扫描、连接、收发蓝牙数据包只懂 HCI 指令不懂 Linux【2】内核层蓝牙核心 HCI 驱动这是蓝牙的 “内核底座”和 Wi-Fi 的 cfg80211 对应。内核模块bluetooth蓝牙核心协议栈hci_uart/hci_usb硬件驱动串口 / USB 蓝牙btusb最常见 USB 蓝牙驱动btsdioSDIO 蓝牙手机 / 嵌入式常用内核做什么提供HCI 协议提供mgmt 管理接口用户态 ↔ 内核管理开关蓝牙、扫描、绑定、连接内核不处理高层业务音频、文件、键盘【3】用户态核心BlueZLinux官方唯一标准蓝牙栈所有发行版都用它。包含两个核心1bluetoothd守护进程最重要蓝牙的 “总管”对应 Wi‑Fi 的wpa_supplicant负责开机、扫描、配对、绑定管理连接提供 DBus 接口给 APP 使用处理所有高层协议2bluetoothctl命令行工具对应 Wi‑Fi 的iw直接控制 bluetoothd常用命令scan on connect AA:BB:CC:DD:EE pair disconnect【4】高层服务蓝牙功能BlueZ 内置所有蓝牙服务A2DP音乐音频音箱 / 耳机HSP/HFP通话音频HID鼠标 / 键盘 / 手柄BLE蓝牙低功耗传感器、手环OBEX文件传输GATTBLE 设备服务三、一次蓝牙连接完整流程超清晰1. bluetoothd 启动 2. 打开蓝牙适配器内核 mgmt 接口 3. 开始扫描SCAN 4. 内核驱动 → 硬件扫描广播 5. 发现设备 → 上报 bluetoothd 6. 配对Pairing→ 密钥交换 7. 连接Connect 8. 跑服务音乐/键盘/传输更多待补充Linux蓝牙子系统同样非常庞大但与WiFi子系统相比它有一个显著的特点蓝牙子系统更依赖用户空间。内核主要负责基础框架和效率敏感的部分而核心的协议栈逻辑和配置文件管理都放在了用户空间。下面我用类似的思路为你梳理蓝牙子系统的整体架构。 核心架构从下到上的分层Linux蓝牙子系统遵循BlueZ项目架构整体分为三层 内核空间net/bluetooth/内核蓝牙子系统位于net/bluetooth/目录它实现了蓝牙核心协议和与硬件交互的接口。核心文件作用关键职责hci_core.cHCI主机控制器接口核心管理蓝牙适配器、处理HCI命令和事件、与驱动交互hci_sock.cHCI Socket提供PF_BLUETOOTH协议族用户空间通过Socket与HCI交互l2cap_core.cL2CAP层核心实现逻辑链路控制与适配协议数据分片和重组sco.cSCO面向同步连接处理音频传输的同步连接rfcomm/core.cRFCOMM模拟串口为传统蓝牙应用提供流控接口bnep/core.cBNEP蓝牙网络封装协议实现蓝牙网络共享PANmgmt.c管理接口BlueZ用户空间通过此接口管理适配器和连接 用户空间BlueZBlueZ是Linux官方蓝牙协议栈它的设计理念是将复杂的策略逻辑从内核移到用户空间这体现在以下几个方面组件路径作用bluetoothdsrc/bluetoothd核心守护进程管理适配器、设备、配置文件和连接策略bluetoothctlclient/bluetoothctl交互式命令行工具用于配对、连接和管理设备D-Bus APIdoc/目录应用程序通过D-Bus与bluetoothd通信而不是直接使用Socketobexdobexd/处理OBEX协议文件传输meshmesh/支持蓝牙Mesh网络这种设计的好处是策略修改和调试不需要重新编译内核且可以利用用户空间的强大工具链。 驱动层drivers/bluetooth/蓝牙驱动相对WiFi驱动要简单一些因为HCI层已经定义好了标准接口驱动只需要处理硬件特定的传输层。驱动类型典型驱动特点USBbtusb.c最通用的蓝牙驱动支持标准USB蓝牙适配器UARThci_uart.c/hci_serdev.c用于嵌入式设备通过串口连接蓝牙模块SDIObtmrvl_sdio.c用于某些WiFi/蓝牙二合一模块BCMbcm2035.c,bcm43xx.cBroadcom芯片专用驱动与WiFi不同蓝牙驱动通常不需要实现复杂的协议逻辑主要工作是发送HCI命令给硬件从硬件接收HCI事件和数据处理固件下载许多蓝牙芯片需要加载固件 核心数据结构理解蓝牙子系统的关键是掌握HCI层的数据结构// 核心结构体代表一个蓝牙适配器 struct hci_dev { char name[8]; // hci0, hci1... struct module *owner; struct device dev; // sysfs设备节点 // 驱动回调函数 int (*open)(struct hci_dev *hdev); int (*close)(struct hci_dev *hdev); int (*send)(struct hci_dev *hdev, struct sk_buff *skb); // 工作队列和状态 struct workqueue_struct *workqueue; unsigned long flags; // 设备信息 bdaddr_t bdaddr; // MAC地址 u8 dev_type; // 主设备或从设备 u8 bus; // USB, UART, SDIO等 // 连接管理 struct list_head conn_hash; // 当前连接列表 struct hci_conn_hash conn_hash; // 统计信息 __u32 stat_cmd_cnt; __u32 stat_evt_cnt; __u32 stat_acl_tx; __u32 stat_acl_rx; }; // HCI命令和事件的通用包格式 struct hci_command_hdr { __le16 opcode; // 操作码 __u8 plen; // 参数长度 } __packed; struct hci_event_hdr { __u8 evt; // 事件类型 __u8 plen; // 参数长度 } __packed; 与WiFi子系统的对比维度WiFi (cfg80211/mac80211)蓝牙 (BlueZ)内核职责实现完整的MAC层逻辑SoftMAC只实现HCI传输和基础协议L2CAP/RFCOMM策略在用户空间用户空间wpa_supplicantiwbluetoothdbluetoothctl接口方式netlink (nl80211)HCI Socket D-Bus驱动复杂度高需要实现ieee80211_ops回调低主要是hci_dev的open/close/send协议复杂度802.11协议非常复杂全在内核核心协议在内核上层协议在用户空间硬件抽象mac80211提供统一的SoftMAC抽象hci层提供统一的HCI命令/事件接口典型问题驱动bug、速率选择、信号弱配对失败、连接不稳定、音频延迟️ 实用工具和调试技巧如果说WiFi子系统是重内核、轻用户的设计那么蓝牙子系统就是轻内核、重用户的典型代表。这种差异源于两种技术的本质WiFi需要在内核中处理高频的数据包传输性能敏感而蓝牙的管理逻辑复杂但数据传输量小更适合在用户空间处理。BT和BLE经典蓝牙和BLE用的是同一套驱动还是两套这是一个非常专业且切中要害的问题。答案是通常情况下经典蓝牙和BLE共用同一套硬件驱动如btusb.c但在驱动之上、协议栈内部它们是两条相对独立、最终又会合的通道。理解这一点对掌握蓝牙驱动的实现至关重要。️ 核心架构同驱异路下图展示了经典蓝牙和BLE在驱动及协议栈层面的关系 技术层面的详解1. 驱动层完全统一无论btusb.cUSB接口还是hci_uart.c串口接口都不会区分接收到的数据是经典蓝牙还是BLE。驱动只做三件事发送HCI命令HCI_OP_...从硬件接收HCI事件收发ACLAsynchronous Connectionless数据包在驱动看来ACL数据包只是固定格式的数据块包头中有一个连接句柄Connection Handle。经典蓝牙和BLE的连接会被分配不同范围的句柄驱动通过这些句柄来区分数据所属的连接但不需要理解句柄背后的协议类型。// 驱动接收ACL数据的统一入口简化自btusb.c static void btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb) { // 从ACL包头中提取连接句柄 struct hci_acl_hdr *hdr (void *)skb-data; u16 handle __le16_to_cpu(hdr-handle); // 驱动不关心这个句柄对应的是经典蓝牙还是BLE连接 // 直接通过HCI层接口上报 hci_recv_frame(data-hdev, skb); }2. 协议栈分流在HCI层之上真正的分流发生在net/bluetooth/内核协议栈中具体在hci_core.c的hci_rx_work()函数中。当收到ACL数据包时// 内核协议栈根据连接类型进行分流 static void hci_acldata_packet(struct hci_dev *hdev, struct sk_buff *skb) { struct hci_conn *conn hci_conn_hash_lookup_handle(hdev, handle); // 根据连接类型分发到不同的处理通道 switch (conn-type) { case ACL_LINK: // 经典蓝牙 l2cap_recv_acldata(conn, skb, flags); break; case LE_LINK: // 低功耗蓝牙 l2cap_recv_acldata(conn, skb, flags); break; // ... } }关键点在于l2cap_recv_acldata()是两者共用的函数。L2CAP层会进一步根据CIDChannel ID判断是经典蓝牙的RFCOMMCID0x0003/0x0005还是BLE的ATTCID0x0004。这种分层设计使得经典蓝牙和BLE能够共享L2CAP层的可靠传输、分片重组等基础设施。3. 重大差异安全管理器唯一真正独立的模块是SMPSecurity Manager Protocol它处理BLE的配对、加密和密钥分发。经典蓝牙则使用传统的HCI命令进行配对如HCI_OP_IO_CAPABILITY_REPLY、HCI_OP_USER_PASSKEY_REPLY。 不同硬件的三种情况硬件类型驱动实现经典蓝牙BLE典型代表传统蓝牙芯片只支持BR/EDR✅❌老款CSR芯片BLE-only芯片只支持LE❌✅TI CC2540双模芯片一套驱动同时处理两种✅✅几乎所有现代芯片BCM43438、Intel 8265、RTL8822等对于双模芯片硬件通常只有一个HCI接口。当驱动发送一个HCI_OP_LE_SET_SCAN_PARAMETERSBLE扫描参数命令时硬件固件会自行判断这是BLE命令并做相应处理。驱动完全不感知这种区分。 为什么这样设计避免代码重复驱动、HCI传输层、L2层的分片重组等基础设施被经典蓝牙和BLE复用节省了约30%的代码量。简化驱动开发驱动开发者只需要实现标准的HCI传输不需要理解两种蓝牙协议的差异。btusb.c可以同时服务于双模芯片和传统芯片。保持向后兼容老设备只需要支持经典蓝牙新设备可以通过同一套驱动接口同时支持两种模式。 实际调试时的意义理解这个架构对你调试蓝牙问题很有帮助问题类型应该查哪里原因驱动层问题如USB传输错误、固件下载失败drivers/bluetooth/btusb.c两种蓝牙共用同一驱动BLE特有功能如GATT连接失败、配对失败net/bluetooth/smp.cBLE的安全管理独立实现经典蓝牙特有功能如A2DP音频卡顿、HFP断连net/bluetooth/rfcomm/或用户空间pulseaudio高层协议在用户空间实现连接建立问题如扫描不到设备net/bluetooth/hci_event.c连接事件处理在HCI层统一进行 总结一句话总结经典蓝牙和BLE共用一套硬件驱动但在内核协议栈的L2CAP层开始分流通过连接句柄区分最终在高层协议完全分离。这种同驱异路的设计是蓝牙子系统优雅性的体现也是理解蓝牙架构的关键。如果你手头有双模蓝牙设备可以用btmon抓取一次连接过程观察HCI日志中ACL数据包的句柄值以及命令类型HCI_CMD与HCI_LE_CMD的交替出现这会让抽象的概念变得非常直观。我的经典蓝牙和wifi共用一块外设BLE单独一个外设这种情况是不是驱动就是分开的是的你这种情况驱动是完全分开的。你的硬件配置是经典蓝牙 WiFi共用一块芯片/模组通常是一个 combo 芯片BLE单独一块芯片/模组这意味着系统中会存在两个独立的蓝牙控制器分别由两个独立的驱动管理。️ 你的系统架构 关键点详解1. 两个独立的 HCI 设备系统启动后你会看到两个蓝牙控制器$ hciconfig -a hci0: Type: Primary Bus: USB BD Address: AA:BB:CC:DD:EE:00 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING Name: BCM43438 Classic Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT # 支持 BR/EDR (经典蓝牙) 和 BLE 双模 hci1: Type: Primary Bus: USB BD Address: 11:22:33:44:55:66 ACL MTU: 27:4 SCO MTU: 0:0 UP RUNNING Name: TI CC2540 BLE Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 Link policy: Link mode: SLAVE ACCEPT # 只支持 BLE (LE Only)2. 驱动可能是相同类型但实例独立虽然驱动代码可能相同比如两个都是btusb.c但它们是两个独立的驱动实例# 查看两个设备使用的驱动 $ lsusb -t /: Bus 01.Port 1: Dev 1, Classroot_hub |__ Port 1: Dev 2, If 0, ClassWireless, Driverbtusb # combo 芯片的蓝牙接口 |__ Port 1: Dev 2, If 1, ClassWireless, Driverbtusb # combo 芯片的另一个接口 |__ Port 2: Dev 3, If 0, ClassWireless, Driverbtusb # 独立 BLE 芯片每个设备都有自己的struct hci_dev结构体USB URB 队列固件加载状态MAC 地址3. BlueZ 如何管理两个控制器bluetoothd可以同时管理多个控制器并支持配置策略# 查看两个控制器的能力 $ bluetoothctl [bluetooth]# list Controller AA:BB:CC:DD:EE:00 BCM43438 Classic [default] Controller 11:22:33:44:55:66 TI CC2540 BLE # 可以选择默认控制器 [bluetooth]# select 11:22:33:44:55:66 [TI CC2540 BLE]# # 或者直接使用特定控制器扫描 [bluetooth]# scan on -c 11:22:33:44:55:664. 典型应用场景外设驱动典型用途Combo 芯片经典蓝牙btusb/hci_uart蓝牙音箱、蓝牙耳机、文件传输、蓝牙网络独立 BLE 芯片btusb/hci_uart低功耗传感器、BLE beacon、蓝牙键盘/鼠标⚠️ 实际开发中需要注意的问题1. MAC 地址冲突两个控制器可能有相同的 MAC 地址某些 combo 芯片会复用 WiFi MAC需要在驱动层或用户空间修正。# 手动设置 BLE 控制器的 MAC 地址 hciconfig hci1 down hciconfig hci1 up hcitool -i hci1 cmd 0x3f 0x001 0x11 0x22 0x33 0x44 0x55 0x662. 固件加载每个控制器可能需要独立的固件文件/lib/firmware/ ├── brcm/BCM43438.hcd # combo 芯片的经典蓝牙固件 ├── ti/cc2540.bin # 独立 BLE 芯片固件3. 电源管理两个控制器可以独立控制电源状态# 只关闭 BLE 控制器保留经典蓝牙 hciconfig hci1 down # 或者只关闭经典蓝牙 hciconfig hci0 down4. 应用层路由应用程序需要知道连接到哪个控制器。例如bluetoothctl需要正确选择控制器才能连接对应类型的设备。 调试技巧当系统中有多个蓝牙控制器时调试时需要指定设备# 针对 hci0经典蓝牙抓取日志 btmon -i hci0 # 针对 hci1BLE抓取日志 btmon -i hci1 # 查看两个控制器的详细状态 cat /sys/kernel/debug/bluetooth/hci0/connections cat /sys/kernel/debug/bluetooth/hci1/connections 总结你的情况确实会导致驱动分离但这不一定是坏事。分离的架构反而让调试和管理更清晰因为你可以独立控制每个外设问题隔离也更简单。关键是要在用户空间通过bluetoothctl的select命令或 D-Bus API明确指定使用哪个控制器避免连接混乱。