treewide: Leverage sdbus++-gen-meson

This makes us more consistent with other projects instead of writing
meson builds for sdbus++ by hand.

Change-Id: I38b69bc67b6a3d80cda1b508a76e106a50d8ab93
Sign

treewide: Leverage sdbus++-gen-meson

This makes us more consistent with other projects instead of writing
meson builds for sdbus++ by hand.

Change-Id: I38b69bc67b6a3d80cda1b508a76e106a50d8ab93
Signed-off-by: Willam A. Kennington III <wak@google.com>

show more ...

sdbus++: Fix meson dependency generation

All of the generated meson files optionally look for sdbus++ sources
that can be plumbed in to allow changes to the generator code to
correctly trigger rebui

sdbus++: Fix meson dependency generation

All of the generated meson files optionally look for sdbus++ sources
that can be plumbed in to allow changes to the generator code to
correctly trigger rebuilds.

This will require adding a new variable prior to generated sources,
`sdbusplusplus_depfiles`. You can convert previous meson defitions with
the follwing.

```
sdbusplus_dep = dependency('sdbusplus')
sdbusplusplus_prog = find_program('sdbus++', native: true)
sdbuspp_gen_meson_prog = find_program('sdbus++-gen-meson', native: true)
sdbusplusplus_depfiles = files()
if sdbusplus_dep.type_name() == 'internal'
sdbusplusplus_depfiles = subproject('sdbusplus').get_variable('sdbusplusplus_depfiles')
endif
```

Change-Id: Ic2d5bafdbdd2595be8c44e0e616e590143639f21
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

server: object: default emit destruct signals

In the mailing list discussion [1] it was observed that there were cases
where daemons like `phosphor-logging` do not end up emitting
InterfacesRemoved

server: object: default emit destruct signals

In the mailing list discussion [1] it was observed that there were cases
where daemons like `phosphor-logging` do not end up emitting
InterfacesRemoved signals even when the holding sdbusplus::object_t was
destructed.

After investigation, we determined that there are valid use cases for not
calling `object->emit_added()` but still wanting the removal signals to be
emitted. Specifically, the case of a daemon creating initial object prior
to claiming a bus-name it is good to omit the emission.

I examined all cases where callers were using `action::defer_emit` and
it was acceptable for all of them to later send the InterfacesRemoved
signals on destruction. To enable the old behavior, if desired, I added
a new enumeration which is `action::emit_no_signals`.

1. https://lore.kernel.org/openbmc/CAGm54UHMED4Np0MThLfp4H-i8R24o8pCns2-6MEzy1Me-9XJmA@mail.gmail.com/

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I70bd5d5f2ecc676bdc9475e8a2a27e02c52d9142

show more ...

format: copy configs from phosphor-dbus-interfaces and reformat

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Id9959785a8f68e95409f643bd5ec4f76591bc885

yaml: format with prettier

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I318c75f7b425e291097ddc2b9ea3f3ceda81b3a7

object: handle diamond inheritance

Commit 664922157bbbd14f0ad1692cee5547f60f6c617c added an inheritance
to `server::object` to gain access to the bus-pointer. This was
observed to cause a compile f

object: handle diamond inheritance

Commit 664922157bbbd14f0ad1692cee5547f60f6c617c added an inheritance
to `server::object` to gain access to the bus-pointer. This was
observed to cause a compile failure in some applications which had a
diamond-inheritance structure due to a nested `object` inheritance:

`object<object<iface0, iface1>, object<iface2, iface3>>`

These clients probably should not have attempted a nested/diamond
because the previous implementation would have resulted in a silent
failure to make `action::emit_interface_added` work properly (since
object itself doesn't have an `emit_added` function).

Improve the `object` so that:
- Diamond inheritance is no longer possible with nested inherits.
- The `action::emit_interface_added` action works properly with
nested inherits.

This required adding some template specialization to determine if one of
the type arguments to `object` were nested (ie.
`object<Args0..., object<Args1...>, Args2...>`) and collapse out the
nested `object` inheritance (so that the example acts exactly the same
as `object<Args0..., Args1..., Args2...>`).

Tested: Enhance the existing `object::emit` test cases to operate on a
nested `object` structure.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I10635a256aafbdc1e42439a49fa61127e06c8e36

show more ...

manager,interface: use shortened types

Use the shortened alias types whenever possible for `manager` and
`interface`.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ib0f10bd0912f366

manager,interface: use shortened types

Use the shortened alias types whenever possible for `manager` and
`interface`.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ib0f10bd0912f3668dcb3fce660a95facdf02c23b

show more ...

bus: shorten bus type

Create an alias `sdbusplus::bus_t` to `sdbusplus::bus::bus` to reduce
duplication.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I9f17892eed5112d4946949861488

bus: shorten bus type

Create an alias `sdbusplus::bus_t` to `sdbusplus::bus::bus` to reduce
duplication.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I9f17892eed5112d49469498614884c02bba86011

show more ...

message: shorten message type

Create an alias `sdbusplus::message_t` to `sdbusplus::message::message`
to reduce duplication.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ib400b12f

message: shorten message type

Create an alias `sdbusplus::message_t` to `sdbusplus::message::message`
to reduce duplication.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ib400b12fe4a412c0c0c3d26a88f3fae46445cfa8

show more ...

message: correctly unpack variants of enums

When a variant contains multiple types which can be converted
from a string (such as two enums, or an enum and string), the
previous code tried a conversi

message: correctly unpack variants of enums

When a variant contains multiple types which can be converted
from a string (such as two enums, or an enum and string), the
previous code tried a conversion from the first type in the
variant. When the first type was an enum, this often threw an
exception. When the first type was a string, this turned into
a plain string containing the dbus enum value.

Add special cases to the variant unpacking to detect types
which are convertible from strings and delegate to a template
specialization of 'convert_from_string' which handles variants.
This specialization will attempt all conversions first and then
revert to a string as a fallback.

Fixes openbmc/sdbusplus#52.

Change-Id: Ide5a0030d595fbaf01122fa8a0ecdaa19ad0078c
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

message: template to check if convert_from_string exists

Add a SFINAE template to determine if convert_from_string
exists for a type.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id:

message: template to check if convert_from_string exists

Add a SFINAE template to determine if convert_from_string
exists for a type.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I5202dacd50734e06a02955ed613e124d8fe0127f

show more ...

test: add tests for enum parsing

Add test cases to cover the parsing of enums from generated
bindings, including two DISABLED test cases to show the issues
reported in openbmc/sdbusplus#52.

Signed-

test: add tests for enum parsing

Add test cases to cover the parsing of enums from generated
bindings, including two DISABLED test cases to show the issues
reported in openbmc/sdbusplus#52.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I5a01529404c38ae6c30aadbdc7d8e20f3ccbcaab

show more ...

sdbus++: support special double values

Enable properties to have default values of special IEEE floating
points: 'NaN', 'infinity' and 'epsilon'.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

sdbus++: support special double values

Enable properties to have default values of special IEEE floating
points: 'NaN', 'infinity' and 'epsilon'.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I7c2daa3c36cde69c2ee06afd75a8d2e77992c6e7

show more ...

sdbus++: handle duplicate generated variant types

4ac7e56e8e18202fad3b2734346c6d4c7a6957fc added support for 'size_t'
and 'ssize_t' types to sdbus++. On some architectures these collide
with '[u]in

sdbus++: handle duplicate generated variant types

4ac7e56e8e18202fad3b2734346c6d4c7a6957fc added support for 'size_t'
and 'ssize_t' types to sdbus++. On some architectures these collide
with '[u]int32_t' or '[u]int64_t' types and so may not be added to a
combined variant (ie. variant<uint32_t, size_t> will fail to compile
on some architectures). The generated bindings in sdbus++ need a
variant from the set of all properties for some of the constructor
forms.

Create a template type which will formulate a non-duplicative type set
from which a variant can be constructed and modify the sdbus++ generator
to use this variant type instead of std::variant directly. Added test
cases here to cover this condition for 'size' and 'ssize' sdbus++ types.

It is possible this could have been resolved in the generator itself,
but then the generator would have needed to know which architecture the
generated bindings were going to be compiled for. This would have made
the header files incompatible between x86-64 and arm32. I chose instead
to keep the header files consistent across all architectures and let the
compiler make the type decision.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I7db5ad2c32d86d37d920a1801cdabfcaeda89489

show more ...

sdbus++: add type 'object_path' alias

The underlying dbus and sdbusplus type is 'object_path', but the
current sdbus++ type is 'path'. Add an alias which is more obvious.

There are currently some

sdbus++: add type 'object_path' alias

The underlying dbus and sdbusplus type is 'object_path', but the
current sdbus++ type is 'path'. Add an alias which is more obvious.

There are currently some users of 'path' is phosphor-dbus-interfaces,
so we cannot immediately remove 'path'. Once this is merged we can
migrate them to 'object_path'.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Iee65fefe890b7bef351a39fa9fec403d3a086a78

show more ...

native_types: add != comparison for string_wrapper

If a 'type: path' is added to a sdbus++ interface YAML file, the
resulting code does not compile due to a missing != comparison
operator for string

native_types: add != comparison for string_wrapper

If a 'type: path' is added to a sdbus++ interface YAML file, the
resulting code does not compile due to a missing != comparison
operator for string_wrapper. Add it and enhance the test case to
cover.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Iaa661a15e58a99e4e816c391152926e9af1a8339

show more ...

sdbus++: add size_t / ssize_t types to YAML

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I4bbbf273e588bdc560c27fc6e208530c19c30f4b

sdbus++: support 'readonly' flag

The previous documentation of 'const' did not match the
specification at a D-Bus level nor the implementation in sdbus++.
Correct the documentation for 'const' and a

sdbus++: support 'readonly' flag

The previous documentation of 'const' did not match the
specification at a D-Bus level nor the implementation in sdbus++.
Correct the documentation for 'const' and add a new 'readonly' flag
which enables the previously documented behavior for 'const.

This was reported by a user outside of the openbmc project which had
already been using the 'readonly' flag in their YAML to identify this
condition. Previously, sdbus++ silently ignored flags it didn't
explicitly support but as of 20255a5fce55a0743dc3d307d1168f18ed553751
this turned into an error.

There are cases of interfaces in 'phosphor-dbus-interfaces' currently
using 'const' where they likely desire a 'readonly' instead. We are
not changing the behavior of 'const' with this commit, so there would
be no regressions induced by this code change.

Resolves openbmc/sdbusplus#48.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I690cb424f5fd00da190343a345ae57ccae393041

show more ...

Emit adding/removing interfaces for object server

The object server currently either creats the objects and interfaces, or
defer the signal by not adding objects.

In practice, we have situations th

Emit adding/removing interfaces for object server

The object server currently either creats the objects and interfaces, or
defer the signal by not adding objects.

In practice, we have situations that the code would like to add
interfaces to an existing object, and it's not supported, or needs
tricky code to workaround.
Exmaples:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-bmc-code-mgmt/+/5820
https://gerrit.openbmc-project.xyz/c/openbmc/openpower-pnor-code-mgmt/+/5346

This commit adds the support by:
1. Adding emit_added() in interface.hpp and the generated server.hpp
2. Adding a enum class in object's constructor to indicate which action
to do, to create the object, or adding the interface, or defer signal
as before.

So the user of object<> could pass `action::emit_interface_added` to the
constructor to tell the object server *only* emit interface added to
DBus, without emitting object added.
The previous code stays the same behavior:
* If `true` is passed in object's constructor, it defers emitting object
added signal;
* If no extra parameter is passed in object's constructor, it emits
object added signal as before.

Tested: 1. Make sure the openbmc builds fine with
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-logging/+/25089
because phosphor-logging uses its own server.hpp for interface, the
above patch removes that.
2. Manually write a small service to verify the interfaces are
added and removed by using the `emit_interface_added` action.
3. Added the unit test cases for object.hpp to check the
ctor/dtor with different actions.

Signed-off-by: Lei YU <mine260309@gmail.com>
Change-Id: I178c5bed3c9ff39ee2ac8d143fbe9131b0753dfa

show more ...