Resource Collaboration Interface Debugging Mechanism
更新时间: 2025/11/19
在Gitcode上查看源码

D-Bus Basics

The Desktop Bus (D-Bus) is an inter-process communication (IPC) mechanism for Linux/Unix systems. Its core design concept is to enable interaction between heterogeneous system components through a standardized message bus architecture.

D-Bus uses a centralized communication architecture, which has inherent limitations in handling high-throughput data transmission and meeting hard real-time requirements. Nevertheless, D-Bus remains valuable in specific application scenarios, particularly in the following aspects:

  1. Standardized hardware resource management interface

    openUBMC provides unified abstraction and management for hardware resources such as sensors and firmware through the bmc.kepler namespace, achieving standardized and interface-based hardware access.

  2. Support for loosely coupled RPC service calls

    D-Bus allows for the breakdown of complex applications into functionally independent, lightweight components. Each component focuses on its own functional implementation without needing to know the internal details of other components. This mechanism significantly improves system modularity, facilitating independent maintenance, replacement, and expansion of components, thereby enhancing the overall architecture flexibility and scalability, which aligns perfectly with the open characteristics advocated by openUBMC.

  3. Communication mechanism based on the resource tree structure

    The resource tree-structured interface provided by D-Bus makes component functions and their dependencies clearer and more defined. This is conducive to implementing layered design and modular management at the system level, providing solid support for the long-term maintainability and architectural evolution of openUBMC.

Resource Collaboration Interface

Based on the D-Bus protocol, mdb_interface is a collection of model definition interfaces for resource collaboration. The detailed descriptions of these interfaces are completed using the module description source (MDS) approach.

Resource definitions in mdb_interface are generally described in JSON format and consists of the path and intf parts. The following table describes the resource attributes.

Basic Resource AttributeDescriptionExample
pathA path used to uniquely identify a resource object, with a hierarchical structure similar to a file system path./bmc/kepler/Managers/1
Note: This path identifies a resource object named "Manager 1."
interfaceEach resource object consists of several interfaces. Each interface can be viewed as a specific type instance, analogous to a class in object-oriented programming (OOP).bmc.kepler.Managers.Time
Note: This interface defines time-related functions in the manager.
propertyProperties under a specific interface of a resource object, analogous to class properties in OOP.DateTime
Note: This property belongs to the time interface and represents the current system date and time.
methodMethods under a specific interface of a resource object, analogous to class methods in OOP.SetDateTime
Note: This method belongs to the time interface and is used to set the system date and time.
signalSignals under a specific interface of a resource object, available for other components to subscribe and listen to.FruAdded
Note: This signal is triggered when a field-replaceable unit (FRU) device is added, carrying the ID and name of that FRU.

busctl Command

busctl is a CLI tool for monitoring and managing D-Bus. It enables users to list objects, interfaces, and methods while providing real-time visibility into message traffic and event triggers across buses in the D-Bus system.

Buses in the D-Bus system are classified into the following types based on the scope:

  • User bus: a D-Bus instance that runs independently for each user session and is responsible for IPC between applications in the session.
  • System bus: a system-level D-Bus instance that operates across the entire operating system (OS), used for communication between system-level processes, including hardware management (such as USB device insertion notifications), system services (such as network management and printer services), and core processes requiring privileged access.

Common Commands

  1. List all services on the user bus of D-Bus.

    bash
    busctl --user list
  2. List the object tree of a service on the user bus of D-Bus.

    bash
    busctl --user tree [service]
  3. List all methods of a specified interface of a specified object on the user bus of D-Bus.

    bash
    busctl --user introspect <service> <object> [interface]
  4. Monitor message passing on the user bus of D-Bus.

    bash
    busctl --user monitor [service] [object]
  5. Display properties of a specified object on the user bus of D-Bus.

    bash
    busctl --user get-property <service> <object> <interface> <property>
  6. Sets the properties of a specified object on the user bus of D-Bus.

    bash
    busctl --user set-property <service> <object> <interface> <property> <SIGNATURE> <ARGUMENT>
  7. Call a method on the user bus of D-Bus.

    bash
    busctl --user call <service> <object> <interface> <method> <SIGNATURE> <ARGUMENT>

Application Examples

For Telnet connection to the IP address of the target environment, you must run the source /etc/profile command before running busctl. For SSH connection, you can directly run busctl without the configuration loading command.

mdbctl Command

In addition to native D-Bus tools, openUBMC also provides a mature object query tool mdbctl. This command primarily operates on MDS objects and is suitable for system debugging and object state queries. It is restricted to users with debugging and diagnostic permissions.

Note that mdbctl is a debugging tool. Its setprop and call commands bypass service logic and operate directly on properties or methods. In principle, it does not provide persistence. Any set property values will not be retained after a system reboot.

Common mdbctl Commands for Debugging Resource Collaboration Objects

The following describes general operation flow of using mdbctl to debug resource collaboration objects:

  1. Connect to the environment and start the tool. Log in to the target environment using SSH and run the mdbctl command to enter the interactive CLI.
  2. View help information. Run the help command to view all supported built-in debugging commands.
  3. Select the target components. Run the lsmc command to view the started components. Run the attach <component_name> command to select the component to interact with. This command can be executed multiple times to select multiple components.
  4. View classes and objects.
    • Run the lsclass <component_name> command to list all the current classes or the classes of a specified module.
    • Run the lsobj <class_name> command to list all objects of a specified class.
  5. Interact with properties.
    • Use lsprop <object_name> [interface_name] to list all properties of a specified object or all properties of a specified interface of a specified object.
    • Run the getprop <object_name> <interface_name> <property_name> command to obtain the specific property value of a specified object.
    • Run the setprop <operation_type> <object_name> <interface_name> <property_name> [parameter_list] command to set the property value of a specified object, where operation_type can be set, unset, or modify.
  6. Interact with methods.
    • Run the lsmethod <object_name> [interface_name] command to list all methods supported by a specified object.
    • Run the call <object_name> <interface_name> <method_name> [parameter_list] command to call a specific method of a specified object.