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 ...

object: handle diamond inheritance

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

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>
Cha

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: I9f17

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 ...

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

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 ...

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, w

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 ...