dbus（一）

dbusplus

参考链接：

dbus介绍

dbus

dbus通信与接口介绍

1、dbus是什么东西？

网上有一篇叫“D-Bus Tutorial”的文章，流传较广。不少介绍dbus的资料，都引用了其中的段落。其实相对于这篇文章，我建议大家直接读“D-Bus Specification”，篇幅不算长，文字也不算枯燥。

D-Bus是针对桌面环境优化的IPC（interprocess communication ）机制，用于进程间的通信或进程与内核的通信。最基本的D-Bus协议是一对一的通信协议。但在很多情况下，通信的一方是消息总线。消息总线是一个特殊的应用，它同时与多个应用通信，并在应用之间传递消息。

DBUS是一种高效、易用的进程间通信方式。DBUS支持进程间一对一和多对多的对等通信，在多对多的通讯时，需要后台进程的角色去分转消息，当一个进程发消息给另外一个进程时，先发消息到后台进程，再通过后台进程将信息转发到目的进程。DBUS后台进程充当着一个路由器的角色。

DBUS中主要概念为总线，连接到总线的进程可通过总线接收或传递消息，总线收到消息时，根据不同的消息类型进行不同的处理。DBUS中消息分为四类：

\1. Methodcall消息：将触发一个函数调用 ；

\2. Methodreturn消息：触发函数调用返回的结果；

\3. Error消息：触发的函数调用返回一个异常 ；

\4. Signal消息：通知，可以看作为事件消息。

DBus分为两种类型：system bus(系统总线)，用于系统(Linux)和用户程序之间进行通信和消息的传递；session bus(会话总线)，用于桌面(GNOME, KDE等)用户程序之间进行通信。

支持dbus的系统都有两个标准的消息总线：系统总线和会话总线。系统总线用于系统与应用的通信。会话总线用于应用之间的通信。网上有一个叫d-feet的Python程序，我们可以用它来观察系统中的dbus世界。

DBUS总线分为系统总线与会话总线两类，两者之前不能互相通信，所以任何应用程序不能欺骗系统事件，安全性很好。

GDBus是GNOME的Gitlab上GLib项目的一部分，而sd-bus是Github上systemd项目的一部分。

在freedesktop.org Gitlab实例上的项目dbus中可获得D-Bus规范的最新版本和参考实现。dbus/dbus

DBUS应用场景

根据DBUS消息类型可知，DBUS提供一种高效的进程间通信机制，主要用于进程间函数调用以及进程间信号广播。

1 . 函数调用

DBUS可以实现进程间函数调用，进程A发送函数调用的请求（Methodcall消息），经过总线转发至进程B。进程B将应答函数返回值（Method return消息）或者错误消息（Error消息）。

2 . 消息广播

进程间消息广播（Signal消息）不需要响应，接收方需要向总线注册感兴趣的消息类型，当总线接收到“Signal消息”类型的消息时，会将消息转发至希望接收的进程。

DBUS通信特点

DBUS是一种低延迟、低开销、高可用性的进程间通信机制。其协议是二进制的，避免序列化的过程，通信效率较高。DUBUS可以提供一些更高层的功能：

\1. 结构化的名字空间；

\2. 独立于架构的数据格式；

\3. 支持消息中的大部分通用数据元素；

\4. 带有异常处理的通用远程调用接口；

\5. 支持广播类型的通信。

DBUS是一种高级的IPC通信机制，通信流程如下图所示。在DBUS通信过程中，存在一个后台进程（BUS Daemon Process）。后台进程和普通进程间信息交互是通过域套接字进行通信。

进程1（Process1）需先连接到总线（dbus_bus_get），其次构造消息（dbus_message_new_signal），然后发送消息（dbus_connection_send）到后台进程。后台进程接收消息，然后根据消息类型对消息进行不同处理（bus_dispatch_matches）。

进程2（Process2）接收消息前需要连接到总线，并告知总线自己希望得到的消息类型（dbus_bus_add_match），然后等待接收消息（dbus_connection_pop_message）。进程2（Process2）收到总线转发的消息时会根据消息类型，做不同的处理（若是信号类型则不需要发送返回值给总线）。

2、Dbus-glib与GDBus

Dbus-glib是GNU标准库，在Dbus接口上封装，方便上层服务与应用更好的使用。其形如一个DBUS代理服务器，由它进行所有DBUS消息的遍历与转发，服务端与消息发送端只需要向DBUSdeamon申请注册唯一的DBUSname 、绑定GOBJECT后，DBUSdeamon就会将申请连到到该DBUSname的DBUS信息转发给指定应用。

dbus-glib 和 GDBus 的区别

Conceptual differences(概念上的区别)

D-Bus最重要的概念在dbus-glib和GDBus中都是相似的.都用对象表示连接,代理 和 方法执行,但也有一些重要的不同点:

• dbus-glib使用 libdbus reference implementation,GDBus不使用,而是依赖GIO流作为传输层,并且拥有一套自己实现的D-Bus连接设置和授权的方法.暂且不说GDBus使用流传输,

​ 不使用libdbus可以使GDBus避免一些多线程方面的问题.

• dbus-glib的方法参数和返回值使用Gobject类型系统,其中包含了一个特定结构的自有容器.GDBus依赖专为匹配D-Bus类型而设计的GVariant类型系统.

• dbus-glib 只能提供D-Bus接口,不为对象提供任何类型;

​ GDBus同时提供D-Bus接口(通过GDBusInterface, GDBusProxy 和 GDBusInterfaceStub 类型)和对象接口(通过GDBusObject, GDBusObjectStub 和 GDBusObjectProxy 类型)

• GDBus 为org.freedesktop.DBus.Properties (通过 GDBusProxy 类型) 和 org.freedesktop.DBus.ObjectManager D-Bus接口,包含了本地支持,dbus-glib没有.

• dbus-glib中导出对象的典型方法是使用dbus-binding-tool根据XML内省数据生成代码,GDBus也提供了一个类似的工具叫做gdbus-codegen,这个工具也可以生成Docbook D-Bus接口文件.

• dbus-glib不提供战友和监视总线名字的方便的API,GDBus提供了g_bus_own_name() 和g_bus_watch_name() 系列的方便函数.

• GDBus提供API来解析、生成 和 工作的内省XML，dbus-glib不提供。

3、sdbusplus

sdbusplus包含两个部分：

1. 一个C ++库（libsdbusplus），用于与D-Bus进行交互，它建立在systemd的sd-bus库之上。
2. 生成C ++绑定以简化基于D-Bus的应用程序开发的工具（sdbus ++）。

依存关系

sdbusplus库需要sd-bus，它包含在libsystemd中。

sdbus ++应用程序需要Python 3和Python库mako和inflection。

C ++库

sdbusplus库建立在sd-bus库的基础上， 以创建用于D-Bus的现代C ++ API。该库尝试尽可能轻量级，通常完全编译为必要的sd-bus API调用，同时还提供现代C ++做法提供的编译时类型安全和内存泄漏保护。

考虑以下代码：

auto b = bus::new_default_system();
auto m = b.new_method_call("org.freedesktop.login1",
                           "/org/freedesktop/login1",
                           "org.freedesktop.login1.Manager",
                           "ListUsers");
auto reply = b.call(m);

std::vector<std::tuple<uint32_t, std::string, message::object_path>> users;
reply.read(users);

在一些相对简洁的C ++行中，此代码片段将创建到系统总线的D-Bus连接，并调用systemd登录管理器以获取活动用户列表。当消息和总线对象离开作用域时，它们将自动释放，并且消息格式字符串将在编译时根据读取的类型生成。将其与logind中的相应服务器代码进行比较。

通常，该库尝试模仿sd-bus库的命名约定：例如。sd_bus_call变成sdbusplus::bus::call， sd_bus_get_unique_name变成sdbusplus::bus::get_unique_name， sd_bus_message_get_signature变成sdbusplus::message::get_signature等等。这允许相对直接地转换回sd-bus函数，以查找手册页详细信息。

sd-bus

sd-bus

在systemd的新v221版本中， 我们宣布systemd 随附的 sd-bus API 稳定。sd-bus是我们最小的D-Bus IPC C库，同时支持经典的基于套接字的D-Bus和 kdbus作为后端。该库已经成为systemd的一部分，但仅在内部使用，因为我们希望自由地进行API更改而不影响库的外部使用者。

D-Bus又是什么？

让我们首先快速提醒一下D-Bus实际上是什么 ：它是用于Linux和其他操作系统的功能强大的通用IPC系统。它了解总线，对象，接口，方法，信号，属性等概念。它为您提供了细粒度的访问控制，丰富的系统，可发现性，自省，监视，可靠的多播，服务激活，文件描述符传递等。在Linux上有许多编程语言的绑定。

十多年来，D-Bus一直是Linux系统的核心组件。它无疑是Linux上建立最广泛的高级本地IPC系统。自systemd诞生以来，它一直是IPC系统，它公开其接口。甚至在systemd之前，它就是IPC系统Upstart用来公开其接口。GNOME，KDE和各种系统组件都使用它。

D-Bus既指规范，又指参考实现。该参考实现同时提供了总线服务器组件和客户端库。尽管有多种其他流行的客户端库重新实现（针对C语言和其他编程语言），但唯一常用的服务器端是参考实现中的一种。（但是，kdbus项目正在努力提供此服务器实现的替代方案，作为内核组件。）

或简单地说：D-Bus很棒。 如果您入侵Linux项目并需要本地IPC，那么它应该是您的首选。 不仅因为D-Bus的设计合理，而且还因为没有很多替代品可以涵盖相似的功能。

SD总线适合放在哪里？

让我们讨论一下为什么sd-bus存在，如何与其他现有的C D-Bus库进行比较，以及为什么它可能是您的项目要考虑的库。

对于C，有两个已建立的流行的D-Bus库：libdbus（它在D-Bus的参考实现中提供），以及GDBus（GLib的组件）GLib（GNOME的低级工具库）。

在这两个libdbus中，有更老的一个，因为它是在规范合并时编写的。该库的编写着眼于可移植性，并可用作高级语言绑定的后端。这两个目标都要求API具有通用性，从而导致相对巴洛克式，难以使用的API，缺少使C语言易于使用和有趣的功能。它提供了构建基块，但实际上没有多少工具可以很容易地从他们那里盖房子。另一方面，该库适用于大多数用例（例如，它是OOM安全的，因此适合编写最低级别的系统软件），并且可移植到Windows或更多奇特的UNIXes等操作系统。

GDBus 是更新得多的实现。它是在使用libdbus周围的GLib / GObject包装器的丰富经验之后编写的。GDBus从头开始实现，不与libdbus共享任何代码。它的设计与libdbus完全不同，它包含代码生成器，以使其特别容易在总线上公开GObject对象，或将D-Bus对象作为GObject对象进行通信。它将D-Bus数据类型转换为GLib强大的数据序列化格式GVariant。如果您习惯使用GLib风格的编程，那么您会感到宾至如归，用它来入侵D-Bus服务和客户端要比使用libdbus简单得多。

现在，通过sd-bus，我们提供了第三个实现，不与libdbus或GDBus共享任何代码。对我们来说，重点是在libdbus和GDBus之间提供一种中间立场：一个实际上很有趣的低级C库，它具有足够的语法糖，可以轻松地使用它编写客户端和服务。另一方面，它比GDBus / GLib / GObject / GVariant更底层。为了能够在systemd的各个系统级组件中使用它，它必须是OOM安全且最小的。除了原始D-Bus规范（“ dbus1”）的套接字传输之外，我们还想集中关注的另一个主要方面是从一开始就支持kdbus后端。实际上，我们希望将库设计为与kdbus的语义更接近，而不是与dbus1的语义更接近，无论它们在何处有所不同，但仍能很好地涵盖这两种传输。与libdbus或GDBus相比，可移植性不是sd-bus的优先事项，相反，我们尝试充分利用Linux平台并在有利的地方公开特定的Linux概念。最后，性能也是一个问题（尽管是次要的）：libdbus和GDBus都不会赢得任何速度记录。我们想提高性能（吞吐量和延迟），但是简单性和正确性对我们来说更为重要。我们相信我们的工作成果可以很好地实现我们的目标：该库使用起来很有趣，支持kdbus和套接字作为后端，相对来说是最小的，并且 libdbus和GDBus都不会赢得任何速度记录。我们想提高性能（吞吐量和延迟），但是简单性和正确性对我们来说更为重要。我们相信我们的工作成果可以很好地实现我们的目标：该库使用起来很有趣，支持kdbus和套接字作为后端，相对来说是最小的，并且 libdbus和GDBus都不会赢得任何速度记录。我们想提高性能（吞吐量和延迟），但是简单性和正确性对我们来说更为重要。我们相信我们的工作成果可以很好地实现我们的目标：该库使用起来很有趣，支持kdbus和套接字作为后端，相对来说是最小的，并且 性能大大优于 libdbus和GDBus。

要决定为您的C项目使用三种API中的哪一种，请参考以下简短指南：

• 如果您入侵GLib / GObject项目，那么GDBus绝对是您的首选。
• 如果对非Linux内核（包括Windows，Mac OS和其他UNIX）的可移植性对您很重要，请使用GDBus（或多或少意味着要购买GLib / GObject）或libdbus（这需要大量的手动工作） 。
• 否则，SD总线将是我推荐的选择。

（我在这里不专门介绍C ++，这仅是关于纯C的。但是请注意：如果您使用Qt，则QtDBus是选择的D-Bus API，是libdbus的包装器。）

systemd包含了一个工具busctl，该工具可用于探索D-Bus对象系统并与之交互。不带参数调用时，它将显示连接到系统总线的所有对等方的列表。

busctl知道许多其他操作。例如，您可以使用它来监视D-Bus通信量（包括生成 .cap文件以供Wireshark！使用），也可以设置或获取特定属性。但是，此博客故事本应是关于sd-bus的，而不是sd-bus的，busctl因此让我们在这里简短介绍一下，如果您想了解更多有关该工具的信息，请允许我转到手册页。

busctl（如系统的其余部分）是使用sd-bus API实现的。因此，它揭示了sd总线本身的许多功能。例如，您可以用来连接到远程或容器总线。它既了解kdbus和经典D-Bus，也了解更多！

root@obmc:~# busctl
NAME                                              PID PROCESS         USER            CONNECTION    UNIT                             
:1.1                                                1 systemd         root            :1.1          init.scope                       
:1.10                                             186 phosphor-certif root            :1.10         [email protected]                         
:1.104                                            446 mctpd           root            :1.104        xyz.openbmc_project.mctpd@FCP_Baseboard_2fMCTP_SMBus_PCIe_slot.service 
:1.11                                             208 phosphor-system root            :1.11         phosphor-systemd-target-monitor.service                                
:1.12                                             202 ipmbbridged     root            :1.12         ipmb.service       
:1.147                                           2318 busctl          root            :1.147        [email protected]
[....]
com.xxxx.crashdump                               173 crashdump       root            :1.5          com.xxxx.crashdump.service     
org.freedesktop.Avahi                             371 avahi-daemon    avahi           :1.85         avahi-daemon.service             
org.freedesktop.DBus                                1 systemd         root            -             init.scope                       
org.freedesktop.hostname1                           - -               -               (activatable) -                               
org.freedesktop.login1                            218 systemd-logind  root            :1.47         systemd-logind.service           
org.freedesktop.network1                          419 systemd-network systemd-network :1.96         systemd-networkd.service       
xyz.openbmc_project.Control.Host.NMI              221 power-control   root            :1.50         xyz.openbmc_project.Chassis.Control.Power.service
[...]

该列表以当前连接到总线的所有对等方的列表开头。它们由对等名称标识，例如“：1.11”。这些在D-Bus术语中称为 唯一名称。基本上，每个对等方都有一个唯一的名称，并且当对等方连接到总线时会自动分配它们。如果您愿意，它们很像IP地址。您会注意到，已经有几个对等节点已经连接，包括我们的小型busctl工具本身以及许多系统服务。然后，该列表显示了总线上的所有实际服务，这些服务由服务名称标识（如上所述）；为了将它们与唯一名称区别开来，这些服务也称为众所周知的名称）。在许多方面，众所周知的名称与DNS主机名类似，即，它们是引用对等方的更友好的方式，但是在较低的级别上，它们仅映射到IP地址，或在此比较中，唯一名称。就像可以通过主机名或IP地址连接到Internet上的主机一样，也可以通过其唯一名称或众所周知的名称连接到总线对等方。（请注意，每个对等方可以根据需要使用任意数量的知名名称，就像IP地址可以引用多个主机名一样）。

root@xxxx-obmc:~# busctl tree xyz.openbmc_project.Control.Host.NMI
`-/xyz
  `-/xyz/openbmc_project
    |-/xyz/openbmc_project/chassis
    | `-/xyz/openbmc_project/chassis/buttons
    |   |-/xyz/openbmc_project/chassis/buttons/id
    |   |-/xyz/openbmc_project/chassis/buttons/nmi
    |   |-/xyz/openbmc_project/chassis/buttons/power
    |   `-/xyz/openbmc_project/chassis/buttons/reset
    |-/xyz/openbmc_project/control
    | `-/xyz/openbmc_project/control/host0
    |   |-/xyz/openbmc_project/control/host0/nmi
    |   `-/xyz/openbmc_project/control/host0/restart_cause
    `-/xyz/openbmc_project/state
      |-/xyz/openbmc_project/state/chassis0
      |-/xyz/openbmc_project/state/host0
      `-/xyz/openbmc_project/state/os

获取对象公开的接口，方法，信号和属性:

root@xxxx-obmc:~# busctl introspect xyz.openbmc_project.Control.Host.NMI /xyz/openbmc_project/chassis/buttons/id
NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface -         -            -
.Introspect                         method    -         s            -
org.freedesktop.DBus.Peer           interface -         -            -
.GetMachineId                       method    -         s            -
.Ping                               method    -         -            -
org.freedesktop.DBus.Properties     interface -         -            -
.Get                                method    ss        v            -
.GetAll                             method    s         a{sv}        -
.Set                                method    ssv       -            -
.PropertiesChanged                  signal    sa{sv}as  -            -
xyz.openbmc_project.Chassis.Buttons interface -         -            -
.ButtonPressed                      property  b         false        emits-change
root@xxxxx-obmc:~# busctl introspect xyz.openbmc_project.Control.Host.NMI /xyz/openbmc_project/chassis/buttons
NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface -         -            -
.Introspect                         method    -         s            -
org.freedesktop.DBus.Peer           interface -         -            -
.GetMachineId                       method    -         s            -
.Ping                               method    -         -            -
org.freedesktop.DBus.Properties     interface -         -            -
.Get                                method    ss        v            -
.GetAll                             method    s         a{sv}        -
.Set                                method    ssv       -            -
.PropertiesChanged                  signal    sa{sv}as  -            -

调用一个方法:

root@xxxx-obmc:~# busctl call xyz.openbmc_project.Control.Host.NMI /xyz/openbmc_project/chassis/buttons/id org.freedesktop.DBus.Peer GetMachineId
s "278dd3da4e8141bfaf4468d662a6dd3d"
root@xxxx-obmc:~# busctl call xyz.openbmc_project.Control.Host.NMI /xyz/openbmc_project/chassis/buttons/id org.freedesktop.DBus.Properties GetAll
Call failed: Expected interface parameter

SD-BUS

但是够了！让我们回到主题上，让我们谈谈sd-bus本身。

sd-bus API集大部分包含在头文件 sd-bus.h中。

这是一个随机选择的库功能，可以与其他可用实现进行比较。

• 同时支持kdbus和dbus1作为后端。
• 对通过ssh连接到远程总线以及本地OS容器的总线具有高级支持。
• 强大的凭据模型，用于实现服务中客户端的身份验证。当前支持34个单独的字段，从客户端的PID到cgroup或功能集。
• 支持跟踪对等方的生命周期，以便在引用它们的所有对等方断开连接时自动释放本地对象。
• 客户端构建有效的决策树，以确定将传入总线消息传递到的处理程序。
• 自动将D-Bus错误转换为UNIX样式错误并反过来（尽管这是有损的），以确保将D-Bus最好地集成到低级Linux程序中。
• 功能强大但轻量级的对象模型，用于在总线上公开本地对象。根据需要自动生成内省。

该API当前尚未完全记录，但是我们正在努力完成手册页面集。有关详细信息， 请参见所有以sd_bus_开头的页面。