[Shenzhen] Yuanchuanghui: 5.26pm, the party hall is waiting for you.”

Column introduction: "Playing with OurBMC" is a knowledge sharing column created by the OurBMC community. It mainly focuses on the sharing of basic knowledge related to the community and BMC full-stack technology, covering all aspects of knowledge transfer from theoretical principles to practical operations. OurBMC community will help developers gain an in-depth understanding of community culture, concepts and characteristics through the "Fun OurBMC" column, and enhance developers' understanding of BMC's full-stack technology.

Welcome everyone to pay attention to the "Fun OurBMC" column and explore the wonderful world of OurBMC community together. At the same time, we sincerely invite all developers to contribute to the "Playing OurBMC" column, learn and make progress together, and build the column into a knowledge garden that gathers wisdom and stimulates creativity.

In OpenBMC , inter-process communication (IPC) is an important component, and D-Bus is widely used as a lightweight and efficient IPC mechanism. This issue will focus on the weaver of this communication network-D-Bus. First, the interfaces and main concepts provided by D-Bus are introduced. Then, a more in-depth analysis of D-Bus is performed based on OpenBMC community applications. Through the analysis of D-Bus, we hope to help readers better understand and use this powerful IPC mechanism to improve the overall performance and stability of the system.

D-bus introduction

D-Bus (Desktop Bus) is an advanced inter-process communication (IPC) mechanism widely used in Linux operating systems. It allows software applications to communicate synchronously or asynchronously, sending and receiving cross-process messages. Compared with traditional IPC mechanisms (such as PIPE/FIFO/Socket/shared memory/SysvIpc), D-Bus provides a low latency , low-overhead and high-availability IPC mechanism, hiding the complexity of the underlying IPC mechanism, providing developers with a more advanced and easy-to-use interface:

Method Call:

Used to implement cross-process method (function) calls, and combined with code generation tools, it can make inter-process function calls almost indistinguishable from ordinary function calls.

Signal:

The communication mechanism of the publish-subscribe (Pub-Sub) model, the sending process registers and sends (broadcast) signals, and the receiving process subscribes to the signals it is interested in.

Properties:

It can be compared to the Getter-Setter of member variables in a C++ class. If process A provides a property, other processes can read and write the property through D-Bus.

At the same time, the following concepts are used to determine the specific object of the D-Bus call:

Bus Name:

The name of a service registered to the bus is a unique name used by each application (or communication object) to identify itself. This name is globally unique to the D-Bus system and can therefore be used by other applications for reference and communication. It can be understood as an "IP" address, analogously to the name of a lib library.

Object Path:

Used to identify objects within a specific application or service on D-Bus , similar to a path in a file system, but used for D-Bus objects instead of files. Object paths usually follow a hierarchical structure for easier organization and management. The naming convention for object paths is /com/example/MusicPlayer1, which represents the root object in an application named "MusicPlayer1". It can be compared to objects of the same class (objects) in C++.

Interface:

The interface defines the functions provided by the D-Bus object, including methods, properties and signals. An interface can be implemented by multiple objects and used by multiple applications or services. An interface is similar to a class or header file in C++, which describes the behavior and accessible properties of an object. In D-Bus, an object can implement multiple interfaces, and each interface contains a set of methods, properties and signals. These methods and properties can be called or accessed by other applications or services through D-Bus.

D-bus practical applications

In OpenBMC, D-Bus is widely used in scenarios such as sensor data collection, hardware fault management, and remote management interfaces. It makes communication between different components simple and efficient, providing a strong guarantee for the stable operation of the system.

The following is a more in-depth analysis of D-Bus based on the actual applications of the OpenBMC community.

D-Bus tool (busctl)

busctl is a command line tool provided by systemd for interacting with the D-Bus system bus. Use the busctl tool to enter the bus name, object path, interface and other parameters to obtain the detailed information provided by the D-Bus object, including properties, signals, method calls ( method), etc., so that users can have a more intuitive understanding of various abstract concepts in D-Bus.

Property

Taking the adcsensor program as an example, this process identifies the chip SOC through the configuration file, converts the original value of the ADC provided by the kernel into voltage, and displays it in the form of D-Bus according to the sensor described in the configuration file:

Bus name: xyz.openbmc_project.ADCSensor

Object path: /xyz/openbmc_project/sensors/voltage/xxx, several object paths are generated according to the board-level configuration file to represent the voltage sensor.

Interface 1: xyz.openbmc_project.Sensor.Value

Properties provided by this interface:

MaxValue (double type): sensor maximum value

MinValue (double type): sensor minimum value

Unit (string type): type of value, volts

Value (double type): current value of the sensor

Interface 2: xyz.openbmc_project.Sensor.Threshold.Critical

Properties provided by this interface:

CriticalAlarmHigh (bool type): Whether the high severity threshold is reached

CriticalAlarmLow (bool type): Whether the low severity threshold is reached

CriticalHigh (double type): critical high threshold

CriticalLow (double type): Critically low threshold

Interface 3: xyz.openbmc_project.Sensor.Threshold. Warning

Properties provided by this interface:

WarningAlarmHigh (bool type): Whether the high warning threshold is reached

WarningAlarmLow (bool type): Whether the low warning threshold is reached

WarningHigh (double type): warning high threshold

WarningLow (double type): warning low threshold

At this point, other application modules can implement related functions through these abstracted D-Bus attributes. For example, the IPMI sensor module can dynamically generate IPMI SDR, the IPMI SEL module monitors attributes and generates alarm logs, and the Redfish module generates sensor redfish interfaces, etc.

Signal

All D-Bus objects will have the org.freedesktop.DBus.Properties interface and the PropertiesChanged signal under it. Any change in any attribute of all interfaces under this object will trigger the signal to be sent to D-Bus. The content format of the signal is sa{sv}as, and the corresponding meaning is:

STRING: interface name

ARRAY of DICT_ENTRY<STRING,VARIANT> attribute name and changed value (multiple)

ARRAY<STRING> The name of the attribute whose value has changed, but the changed value is unknown. (multiple)

In addition, all D-Bus messages will contain bus name and object path, and other processes can freely select these parameters for monitoring to capture variables of interest.

Method

There are only two types of messages on the D-Bus bus, one is Signal and the other is Method. The main differences between the two are as follows:

1. Signal is broadcast on the bus, while Method is a message sent to a characteristic object;

2. Signal has no return value, while Method can have a return value (synchronous or asynchronous), depending on whether the called method defines a return value;

3. Signal is mainly used for event notification, while Method is usually used to request data or perform operations;

Reading and writing Property is essentially a method of calling Get and Set in the Dbus standard interface org.freedesktop.DBus.Properties .

Take the method of creating a network card IP address as an example:

Bus Name：xyz.openbmc_project.Network

Object：/xyz/openbmc_project/network/<network_name>

Interface：xyz.openbmc_project.Network.IP.Create

Method：IP ssys：“<IP Protocol>：ipv6\ipv4”“<IP Address>” “<Netmask Prefix>” “<Network Gateway>”,return “New IP Object Path”

Use the busctl tool to create an IP:

busctl --verbose call xyz.openbmc_project.Network /xyz/openbmc_project/network/eth0 xyz.openbmc_project.Network.IP.Create IP ssys "xyz.openbmc_project.Network.IP.Protocol.IPv4" "10.10.10.192" 24 "10.10.10.1"

return value:

MESSAGE "o" {

OBJECT_PATH "/xyz/openbmc_project/network/eth0/_310_2e10_2e10_2e192_2f24";

};

You can also think of the IP method of the xyz.openbmc_project.Network.IP.Create interface as a function that inputs IP information, adds an IP address to the network card, and returns a newly generated object path:

string IP(string protocol,string ip_addr,unsigned char netmask,string gateway)

In short, D-Bus is one of the important mechanisms for inter-process communication in OpenBMC. It enables different processes and applications to communicate with each other by providing a reliable and flexible message bus system. It simplifies the complexity of inter-process communication and provides many useful functions, thereby improving the reliability and maintainability of the OpenBMC system.

Welcome everyone to follow OurBMC community and learn more about BMC technology.

OurBMC community official website:

https://www.ourbmc.cn/

Playing with OurBMC Issue 7: OpenBMC inter-process communication D-Bus

D-bus introduction

D-bus practical applications

Guess you like