D-Bus interfaces can be defined by creating a YAML file to describe the methods, properties, and signals they contain. From this YAML file, both documentation and binding code may be generated.
An interface YAML may have the following sections:
A common problem we have found with D-Bus interfaces is having a consistent way to define enumerations. Two common practices are to either assign special meaning to integers, as a C compiler might do, or to have specific strings representing the enumeration name. The D-Bus API design guidelines specify both of these options:
For APIs being used in constrained situations, enumerated values should be transmitted as unsigned integers. For APIs which need to be extended by third parties or which are used in more loosely coupled systems, enumerated values should be strings in some defined format.
What we have done in sdbus++
is to consider enumerations as a first-class type. Within an interface you can define an enumeration and the bindings will have a C++ enumeration defined for it. At a D-Bus level any property or method parameter will be a string, but the string will contain a fully-qualified name "interface.enum-name.enum-value" like "org.freedesktop.Example.Color.Red". Within the generated bindings, an automatic conversion is done between strings and C++ enumeration values and clients will get an "xyz.openbmc_project.sdbusplus.Error.InvalidEnumString" error response if they attempt to use an invalid string value.
An enumeration must have the YAML properties name
and values
and may optionally contain a description
. The name
is a word corresponding to the desired "enum-name" portion of the fully-qualified name and the resulting C++ enum type. The values
are a list of enumeration values each containing their own name
and optional description
.
Example:
enumerations: - name: Suits description: > The suits found in a deck of cards. values: - name: Diamonds - name: Hearts - name: Clubs description: > This is the suit that looks like a clover. - name: Spades
Types are identified in YAML using their typename found in the D-Bus specification, but listed using lowercases: int64
instead of INT64
or C++ int64_t
.
Container types can also be expressed, but the contained-type should be expressed within square-brackets []
. The following containers are supported:
array[type]
std::vector
struct[type0, type1, ...]
std::tuple
variant[type0, type1, ...]
std::variant
dict[keytype, valuetype]
std::map
It may seem odd that variants are required to list the types they may contain, but this is due to C++ being a strongly-typed language. In order to generate bindings, to read from and append to a message, the binding generator must know all possible types the variant may contain.
Enumerations are expressed like a container, but the contained-type is an identifier of the fully-qualified enum-name or a shortened self.
identifier for locally defined types.
A method must have the YAML property name
and may optionally have parameters
, returns
, flags
, errors
, and description
. Each parameter must have a name
, type
, and optional description
. Each return must have a type
and may optionally have a name
and description
. Flags are a list of sd-bus vtable flags; the supported values are deprecated
, hidden
, unprivileged
and no_reply
, which corresponds to SD_BUS_VTABLE_DEPRECATED
, SD_BUS_VTABLE_HIDDEN
, SD_BUS_VTABLE_UNPRIVILEGED
, SD_BUS_VTABLE_METHOD_NO_REPLY
, respectively. Errors are a list of fully-qualified or shortened self.
identifiers for errors the method may return, which must be defined in a corresponding errors YAML file.
Example:
methods: - name: Shuffle flags: - unprivileged errors: - self.Error.TooTired - name: Deal description: > Deals a new hand to each player. errors: - self.Error.OutOfCards - name: LookAtTop returns: - name: Card type: struct[enum[self.Suit], byte] - name: MoveToTop flags: - deprecated - no_reply parameters: - name: Card type: struct[enum[self.Suit], byte]
A property must have the YAML property name
and type
and may optionally have description
, flags
, default
, and errors
. The default
defines the default value of the property. See the Methods
section above for more information on errors.
The supported values for flags
are deprecated
, hidden
, unprivileged
, const
, emits_change
, emits_invalidation
, explicit
, which corresponds to SD_BUS_VTABLE_DEPRECATED
, SD_BUS_VTABLE_HIDDEN
, SD_BUS_VTABLE_UNPRIVILEGED
, SD_BUS_VTABLE_PROPERTY_CONST
, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE
, SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION
and SD_BUS_VTABLE_PROPERTY_EXPLICIT
, respectively. The flag const
makes the property read-only via D-Bus but still writable by the app implementing it. Moreover, if no flags have been specified for a property, emits_change
will be added by default.
Example:
properties: - name: CardsRemaining type: uint32 default: 52 flags: - const description: > The number of cards remaining in the deck. errors: - self.Error.InvalidNumber
A signal must have the YAML property name
and may optionally have a description
and list of properties
. Properties are specified the same as interface properties.
Example:
signals: - name: Shuffled description: > The deck has been shuffled. - name: Cheated properties: - name: CardToTop type: struct[enum[self.Suit], byte]