01 - D-Bus 概念与历史

第 01 章：D-Bus 概念与历史

1.1 为什么需要 D-Bus？

在 Linux 系统中，进程之间经常需要交换数据。比如：

• 桌面通知服务需要知道哪个应用发来了消息
• systemd 需要监听服务状态变化
• 蓝牙守护进程需要将设备信息传递给 UI
• 容器运行时需要与宿主机 daemon 通信

这些场景统称为 进程间通信（Inter-Process Communication, IPC）。Linux 提供了多种 IPC 机制：

D-Bus 并非取代底层 IPC，而是在其之上构建了一套 高层语义框架：

┌───────────────────────────────────────────┐
│          应用程序 / 系统服务               │
├───────────────────────────────────────────┤
│          D-Bus 协议层                      │  ← 方法调用、信号、属性
├───────────────────────────────────────────┤
│          D-Bus 守护进程 (dbus-daemon)      │  ← 路由、激活、策略
├───────────────────────────────────────────┤
│     Unix Domain Socket / TCP              │  ← 传输层
└───────────────────────────────────────────┘

1.2 核心概念

1.2.1 消息总线（Message Bus）

D-Bus 的核心是一条 消息总线，它是一个中心化的守护进程，所有参与者都连接到总线上，通过总线路由消息。

  App A ──┐                    ┌── App C
           │    ┌──────────┐   │
  App B ──┼───→│ dbus-daemon│←──┼── systemd
           │    └──────────┘   │
  App D ──┘                    └── NetworkManager

核心优势：

• 解耦：发送方不需要知道接收方的地址
• 广播：一条消息可以送达多个订阅者
• 激活：目标服务未运行时，总线可以自动启动它

1.2.2 三种通信模式

1.2.3 三大名称概念

D-Bus 使用三种名称来标识通信对象：

总线名称（Bus Name）— 标识连接到总线上的服务进程：

org.freedesktop.NetworkManager     # 系统服务
org.gnome.Nautilus                 # 桌面应用
:1.42                              # 唯一名称（连接时自动分配）

对象路径（Object Path）— 标识服务内部的对象实例：

/org/freedesktop/NetworkManager
/org/freedesktop/NetworkManager/Devices/0
/com/example/Calculator

接口名称（Interface）— 标识对象上的一组方法/信号/属性：

org.freedesktop.DBus.Properties
org.freedesktop.DBus.Peer
org.freedesktop.NetworkManager

类比：总线名称 ≈ 公司名称，对象路径 ≈ 部门/工位，接口名称 ≈ 职能角色

1.3 D-Bus 与 Unix Socket 对比

选择建议：

• 需要最低延迟和最高吞吐 → Unix Domain Socket
• 需要服务发现和标准化接口 → D-Bus
• 两者并不互斥：D-Bus 底层就使用 Unix Domain Socket 作为传输层

1.4 适用场景

✅ 适合使用 D-Bus 的场景

❌ 不适合使用 D-Bus 的场景

1.5 D-Bus 的历史

注意：kdbus 项目最终未合并入 Linux 内核。当前 D-Bus 仍然运行在用户态（dbus-daemon 或 dbus-broker），通过 Unix Domain Socket 传输。

1.6 一次 D-Bus 通信的完整流程

以 d-feet 查询 NetworkManager 的设备列表为例：

1. d-feet 连接到 Session Bus
   → dbus-daemon 分配唯一名称 :1.99

2. d-feet 发起方法调用：
   Bus Name:  org.freedesktop.NetworkManager
   Object:    /org/freedesktop/NetworkManager
   Interface: org.freedesktop.NetworkManager
   Method:    GetDevices

3. dbus-daemon 收到消息，查找 org.freedesktop.NetworkManager
   → 如果服务未运行且有 .service 激活文件，则启动它

4. NetworkManager 处理请求，返回设备路径数组

5. dbus-daemon 将回复路由回 :1.99（d-feet）

6. d-feet 显示结果

让我们实际验证这个流程：

# 步骤 1：查看当前 Session Bus 上有哪些名称
busctl --user list

# 步骤 2：调用 NetworkManager 的 GetDevices（需要 System Bus 权限）
busctl call \
  org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager \
  org.freedesktop.NetworkManager \
  GetDevices

# 步骤 3：查看 D-Bus 自身的信息
busctl call \
  org.freedesktop.DBus \
  /org/freedesktop/DBus \
  org.freedesktop.DBus \
  GetId

1.7 D-Bus 守护进程的两种实现

# 查看当前使用的守护进程
ps aux | grep dbus
# 输出可能是：
# /usr/bin/dbus-daemon --session --address=systemd: --nofork
# 或
# /usr/bin/dbus-broker-launch --scope user

注意：现代发行版（如 Fedora 31+、Arch Linux）默认使用 dbus-broker。两者的 D-Bus 协议完全兼容，区别仅在守护进程的实现。

1.8 快速体验：发送你的第一条消息

# 列出 Session Bus 上所有名称
dbus-send --session --dest=org.freedesktop.DBus \
  --type=method_call --print-reply \
  /org/freedesktop/DBus \
  org.freedesktop.DBus.ListNames

输出示例：

array [
   string "org.freedesktop.DBus"
   string ":1.0"
   string ":1.42"
   string "org.gnome.Shell"
   string "org.freedesktop.portal.Desktop"
   ...
]

恭喜！你已经成功通过 D-Bus 与总线守护进程进行了一次完整的通信。

本章小结

扩展阅读

• D-Bus 官方规范
• D-Bus 低层 API（wire protocol）
• Havoc Pennington 的原始设计文档
• Arch Wiki: D-Bus
• Lennart Poettering: kdbus 与 D-Bus 的未来