深入解析Bluez Inquiry机制：从用户空间到内核的完整流程

1. 引言：为什么需要理解Bluez Inquiry流程？

如果你在Linux系统上用过蓝牙，无论是连接耳机、传输文件，还是用蓝牙鼠标，背后都离不开一个默默工作的守护进程——Bluez。而“扫描发现周围设备”这个看似简单的操作，在Bluez协议栈里却是一场跨越用户空间和内核空间的精密协作。很多开发者，尤其是做嵌入式蓝牙产品或者进行蓝牙协议栈二次开发的同行，都曾遇到过这样的困惑：为什么我的设备有时候扫描不到？为什么扫描结果时有时无？为什么修改了某个参数后，整个发现机制就“罢工”了？

要解决这些问题，仅仅会使用bluetoothctl的scan on命令是远远不够的。你需要深入到代码层面，搞清楚从你在终端敲下命令，到内核里的蓝牙芯片真正开始广播询问，再到把扫描到的设备列表呈现给你，这中间到底发生了什么。这个过程，就是Inquiry（设备发现）的完整流程。理解它，不仅能帮你高效地调试问题，更能让你对Linux蓝牙子系统有一个立体的认识，知道用户空间的bluetoothd、内核的HCI层、以及它们之间通过mgmt socket的通信是如何环环相扣的。

我自己在早期做蓝牙网关项目时就踩过不少坑。有一次，设备在连续扫描一段时间后就会卡死，重启蓝牙服务才能恢复。当时就是靠一步步追踪这个Inquiry流程，最终定位到是用户空间处理event事件的一个回调函数里出现了资源未释放的问题。所以，今天我就把自己梳理的这套从用户空间到内核的完整流程分享出来，希望能帮你少走弯路。

2. 起点：bluetoothctl与D-Bus的魔法

一切故事都从我们最熟悉的命令行工具bluetoothctl开始。当你打开蓝牙适配器后，输入scan on，一场复杂的旅程就此启动。

2.1 bluetoothctl如何解析你的命令

在bluetoothctl的源代码（通常在client/目录下）里，scan on这个命令最终会走到cmd_scan()函数。这个函数的核心逻辑其实很清晰：它判断你是要开启还是关闭扫描，然后准备通过D-Bus去调用蓝牙守护进程（bluetoothd）里的对应方法。关键点在于，它并不是直接去操作硬件或内核，而是作为一个D-Bus客户端，向作为D-Bus服务端的bluetoothd发送一条消息。

// 简化后的逻辑
if (enable == TRUE) {
    method = "StartDiscovery";
} else {
    method = "StopDiscovery";
}
g_dbus_proxy_method_call(default_ctrl->proxy, method, NULL, start_discovery_reply, ...);

这里的method就是字符串"StartDiscovery"。g_dbus_proxy_method_call这个函数是GLib的D-Bus封装，它会构造一条标准的D-Bus方法调用消息。这条消息里包含了几个关键信息：服务名（org.bluez）、对象路径（通常是/org/bluez/hci0，代表第一个蓝牙适配器）、接口名（org.bluez.Adapter1）和方法名（StartDiscovery）。你可以把它想象成寄一封信，收件地址和要办的事情都写得清清楚楚。

2.2 D-Bus消息的旅程

这条D-Bus消息通过系统总线（System Bus）发出后，一直在监听总线消息的bluetoothd进程就会收到它。bluetoothd内部维护着一个方法表，用来将接口和方法名映射到具体的处理函数。对于org.bluez.Adapter1接口的StartDiscovery方法，其处理函数就是src/adapter.c文件里的start_discovery()函数。

这里有个细节值得注意：bluetoothd支持多个客户端同时连接。比如，你可能同时用着bluetoothctl和一个图形化的蓝牙管理工具。因此，start_discovery()函数的第一件事就是检查是哪个D-Bus发送者（sender）发起的请求，并为这个发送者创建一个discovery_client结构来管理其扫描状态。这保证了不同客户端的扫描请求不会相互干扰。如果同一个客户端重复发起扫描请求，它会收到一个“繁忙”的错误提示。

3. 核心枢纽：bluetoothd守护