Added flags parameter to register_property method

- flags parameter is set by default to vtable::property_::emits_change
- with this change user can set parameter to vtable::property_::none
to avo

Added flags parameter to register_property method

- flags parameter is set by default to vtable::property_::emits_change
- with this change user can set parameter to vtable::property_::none
to avoid sending property change signal for greater performance
- added example/register-property.cpp with example application
which uses new functions

Tested:
- run openbmc tests with this change, no regression detected
- tested that default behaviour (property_::emits_change) is working as intended
- tested that properties still signal change when emit_change flag is used
- tested that properties doesn't signal change when no emit_change flag is used
- tested that const flag is passed and handled corretly
- verified that performance of application increases when emit_change flag turned off

Signed-off-by: Krzysztof Grobelny <krzysztof.grobelny@intel.com>
Change-Id: If6187cf076b8e05a5211c83797374a3be94da0c9

show more ...

build: Add options for tweaking what is built

We don't need to always build tests or examples so make it possible for
the user to configure what is built. The default is to automatically
build them

build: Add options for tweaking what is built

We don't need to always build tests or examples so make it possible for
the user to configure what is built. The default is to automatically
build them if possible.

Change-Id: I5cb6b1689c408188f14d1fcbcfb0006c17f1c90d
Signed-off-by: William A. Kennington III <wak@google.com>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

test: fix boost dependency for bus/aio

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

build: Move boost dependency into example

This simplifies the build check by using disabler objects, and will
remove the need to do the dependency check if we disable examples. They
will be disabled

build: Move boost dependency into example

This simplifies the build check by using disabler objects, and will
remove the need to do the dependency check if we disable examples. They
will be disabled for subprojects.

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

show more ...

Add support for vtable flags for methods

This adds support for specifying the vtable flags
SD_BUS_VTABLE_DEPRECATED, SD_BUS_VTABLE_HIDDEN,
SD_BUS_VTABLE_UNPRIVILEGED and SD_BUS_VTABLE_METHOD_NO_REPL

Add support for vtable flags for methods

This adds support for specifying the vtable flags
SD_BUS_VTABLE_DEPRECATED, SD_BUS_VTABLE_HIDDEN,
SD_BUS_VTABLE_UNPRIVILEGED and SD_BUS_VTABLE_METHOD_NO_REPLY for
methods. The list of flags in the YAML file will be ORed together.

Change-Id: I7762ffb15a1483760f3b7e0ea02e80fd52ebd9b9
Signed-off-by: Waqar Hameed <waqarh@axis.com>

show more ...

build: remove autotools builds

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

meson: create structure for use as submodule

Some other openbmc projects have set up sdbusplus to use as a
meson-subproject. When porting one of them (entity-manager) to use
the meson build, I real

meson: create structure for use as submodule

Some other openbmc projects have set up sdbusplus to use as a
meson-subproject. When porting one of them (entity-manager) to use
the meson build, I realized we are not structuring our meson.build
file according to best-practices for consumption as a submodule.
Specifically, we are missing the 'sdbusplus_dep' variable as described
in the meson reference: https://mesonbuild.com/Subprojects.html

Now that 'sdbusplus_dep' is defined, use it throughout the rest of
the meson.build files as well for simplification.

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

show more ...

meson: feature match autotools support

Add support to build the example and test directories, which
will get us feature match with the current autotools-based build.

Signed-off-by: Patrick Williams

meson: feature match autotools support

Add support to build the example and test directories, which
will get us feature match with the current autotools-based build.

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

show more ...

clang-format: sync from docs master .clang-format

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

clean up more pedantic compile warnings

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

sdbus++: Generate initial client header

By "client-header" option, sdbus++ could generate a client header file
that provides the code used by the client.

Currently it only includes the interface na

sdbus++: Generate initial client header

By "client-header" option, sdbus++ could generate a client header file
that provides the code used by the client.

Currently it only includes the interface name's string in the header
file, it could be extended in the future.

The client header could be merged together for all the interfaces, so
that an interface library could provide a single header to represent all
the interface strings.

Usage:

sdbus++ -r $(srcdir) -t $(top_builddir)/tools/sdbusplus/templates \
interface client-header <interface>

Tested: Generate the header in example and use static_assert to verify
it is the same as the interface defined in the interface calss.

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

show more ...

asio: Allow mutable lambdas + small cleanup

There are many cases in which we want to have a mutable
capture so that the lambda takes over the parameter and
we can modify it after the async callback.

asio: Allow mutable lambdas + small cleanup

There are many cases in which we want to have a mutable
capture so that the lambda takes over the parameter and
we can modify it after the async callback. By making the
top level lambda mutable, the users callback can be mutable.

Also remove a couple references to experimental and a copy
that I saw when I was fixing this issue.

Tested: Added test and made sure that refish which uses
many async_method_calls still worked fine

Change-Id: Ifb1f9d8b9217187799e2defe429e76a937297ca1
Signed-off-by: James Feist <james.feist@linux.intel.com>

show more ...

Change async_method_call to be no-throw

The async_method_call() would throw despite the inferred promise that it
would not, because the handler would be passed an error_code object. But
that would o

Change async_method_call to be no-throw

The async_method_call() would throw despite the inferred promise that it
would not, because the handler would be passed an error_code object. But
that would only protect from the dbus method call itself. When it came
time to unpack the response, the read_into_tuple(...) method call would
throw if the received types did not match the expected types. And
because this throw would happen in a separate boost::asio context, the
throw would always be fatal. Now, any exception during the D-Bus call or
unpacking of parameters will result in an error_code getting passed into
the handler so it can take appropriate action.

This also updates the example to remove try/catch statements around the
async_method_call and yield_method_call examples and shows what happens
if the method calls fail because of different types of errors
(api/function does not exist vs. incorrect unpack types).

Tested-by: run asio-example to see that it works as expected:
# /tmp/asio-example
voidBar() -> 42
fooYield(yield, 41)...
async_send callback
error with async_send
ipmiInterface:execute(61)
async_method_call callback
/org/openbmc/control/bmc0
/org/openbmc/control/flash/bmc
fooYield(yield, 41)...
ipmi call returns OK!
foo(41) -> 42
async_method_call callback
async_method_call expected failure: generic:foo(41) -> 42
yielding call to foo OK! (-> 42)
22
async call to Properties.Get serialized via yield OK!
TestYieldFunction return 42
yielding call to foo OK! (-> 42)
yielding call to TestYieldFunction serialized via yield OK!
fooYield(yield, 41)...
foo(41) -> 42
async call to Properties.Get serialized via yield OK!
yielding call to foo OK! (-> 42)
TestYieldFunction expected error: generic:22
TestYieldFunctionNotExits expected error: generic:53
*** tick ***
*** tock ***
*** tick ***
*** tick ***
*** tick ***

Change-Id: I53c91484ed496556342b3ed0a58b690872a2d676
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

stuff

Change-Id: I48da27be7ba8c63f44c12a8b79fffb8f3e085648
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

Change yield_method_call to be no-throw

The yield_method_call() would throw despite the inferred promise that it
would not, because the caller could attach an error_code to the yield
object. But tha

Change yield_method_call to be no-throw

The yield_method_call() would throw despite the inferred promise that it
would not, because the caller could attach an error_code to the yield
object. But that would only protect from the dbus method call itself.
When it came time to unpack the response, the read(...) method call
would throw if the received types did not match the expected types. Now,
the method forces you to pass in an error_code and it will always return
the appropriate error instead of throw.

Tested-by: run asio-example to see that it works as expected:
# /tmp/asio-example
voidBar() -> 42
async_send callback
error with async_send
async_method_call callback
/org/openbmc/control/bmc0
/org/openbmc/control/flash/bmc
fooYield(yield, 41)...
ipmiInterface:execute(61)
ipmi call returns OK!
fooYield(yield, 41)...
foo(41) -> 42
async call to Properties.Get serialized via yield OK!
foo(41) -> 42
yielding call to foo OK! (-> 42)
TestYieldFunction return 42
yielding call to foo OK! (-> 42)
yielding call to TestYieldFunction serialized via yield OK!
async call to Properties.Get serialized via yield OK!
*** tick ***
*** tock ***
*** tick ***
*** tick ***
*** tick ***
*** tick ***
*** tick ***

Change-Id: Iea43acd432107b4149f8e549310cfce2518cbc1d
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

std::variant: Remove uses of the variant_ns

Now that we are using std::variant we should reference it directly
instead of using our own namespace alias.

Tested:
Built and ran through unit tests

std::variant: Remove uses of the variant_ns

Now that we are using std::variant we should reference it directly
instead of using our own namespace alias.

Tested:
Built and ran through unit tests.

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

show more ...

Move asio interfaces away from deprecated names

The intent of this commit is to allow building asio based event loops in
applications with BOOST_ASIO_NO_DEPRECATED flag set. This change is
largely

Move asio interfaces away from deprecated names

The intent of this commit is to allow building asio based event loops in
applications with BOOST_ASIO_NO_DEPRECATED flag set. This change is
largely a sed replace of io_service with io_context.

This will allow us to move to the networking TS at such time that it is
mature. Details on depreated interfaces are available here for
reference:

https://www.boost.org/doc/libs/1_69_0/doc/html/boost_asio/net_ts.html

Change-Id: Ie3cc699effcf855a649dee5bfce2f6616109429b
Signed-off-by: Ed Tanous <ed.tanous@intel.com>

show more ...

asio: Update variant usage

After the below change in sdbusplus,
the variant usage needs to be switched to std::variant
https://github.com/openbmc/sdbusplus/commit/90778b430290c9ec8c33fb77b03e2552d9d

asio: Update variant usage

After the below change in sdbusplus,
the variant usage needs to be switched to std::variant
https://github.com/openbmc/sdbusplus/commit/90778b430290c9ec8c33fb77b03e2552d9dd6905

Tested:
./configure --enable-boost
make

Change-Id: Ic1d156ad379eb56822f75e8046f83fa45f4ad56d
Signed-off-by: Yong Li <yong.b.li@linux.intel.com>

show more ...

sdbusplus: better mirror bus aquisition methods

This adds new functions:
* new_default_user() -> return default user bus connection
* new_default_system() -> returns default system connection

And

sdbusplus: better mirror bus aquisition methods

This adds new functions:
* new_default_user() -> return default user bus connection
* new_default_system() -> returns default system connection

And changes new_default() to return the default type of connection for
the user as per the man page:
https://www.freedesktop.org/software/systemd/man/sd_bus_default.html

Also, update the example and the README to use the default bus calls.

Change-Id: I13cd77dda847c4f6018da38e0019816da07710d1
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

Add sdbusplus::asio coroutine method handling

Adding the server-side of the coroutine path allows yielding
asynchronous method handling via coroutines. This means that a method
handler can call a yi

Add sdbusplus::asio coroutine method handling

Adding the server-side of the coroutine path allows yielding
asynchronous method handling via coroutines. This means that a method
handler can call a yielding dbus call (or other asio-based asynchronous
call) without blocking the rest of the process.

The call path might look something like this:

service.thing/object/path/interface.my-method()
- do something
- yield_method_call(other.service, /other/path,
other.interface, other-method)
<yields to other coroutine>

execute other code in another context

<returns some time later with dbus call's response>
- use response from other method
<- return my-method response

This also changes the asio-example, pulling it apart into a
client/server model so it is more clear about how to use the yielding
async method handling and yielding async method calls.

Change-Id: I23ccf7a9a8dff787be78929959c1f018280a0392
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

Avoid build failure when sdbus++ tool is disabled

Few examples provided as a part of the repository are dependent on the
sdbus++ code generation tool, and the compilation will fail trying to
build t

Avoid build failure when sdbus++ tool is disabled

Few examples provided as a part of the repository are dependent on the
sdbus++ code generation tool, and the compilation will fail trying to
build the examples even in cases where the user disables sdbusapp during
configuration using --disable-sdbuspp option.

- Made a change in example/Makefile.am to build the examples which are
dependent on sdbus++ tool(which is dependent on few python packages)
only when the sdbuspp is enabled during configuration.

Resolves openbmc/sdbusplus#19

Change-Id: I1453536fd4c7df35e66f2ccfe7a890cced0d155d
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>

show more ...

Add coroutine support for sdbusplus::asio method calls

Using a coroutine to asynchronously execute method calls gives the best
of both worlds:
1) better readability because the code reads like synch

Add coroutine support for sdbusplus::asio method calls

Using a coroutine to asynchronously execute method calls gives the best
of both worlds:
1) better readability because the code reads like synchronous code
2) better throughput because it is actually asynchronous

When passed in a boost::asio::yield_context, the sdbusplus::asio dbus
connection members async_send and async_method_call will execute
asynchronously using coroutines.

This also adds an example of how this works in the
example/asio-example.cpp file.

Change-Id: Ifb71b2c757ecbfd16b3be95bdefc45a701ca0d51
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

sdbus::asio: service sd_event loop upon request

If requested, add in an asynchronous sd_event servicing mechanism so
sd_events can be used in conjunction with boost::asio events. Code
throughout the

sdbus::asio: service sd_event loop upon request

If requested, add in an asynchronous sd_event servicing mechanism so
sd_events can be used in conjunction with boost::asio events. Code
throughout the openbmc repositories use sd_events, especially for
timers. In some cases, we may want to add boost::asio event handling for
superior asynchronous eventing, but not want to rewrite all the existing
sd_event code. This gives us the best of both worlds, with a
low-overhead mechanism to handle the sd_events.

Change-Id: I3f8e2aafa3f733439e1494253698d17c2f3a2321
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

sdbusplus::asio: fix callback with void args specialization

Callbacks with no arguments failed to build due to an error in the
utility::get_first_arg template. It failed to provide a type member for

sdbusplus::asio: fix callback with void args specialization

Callbacks with no arguments failed to build due to an error in the
utility::get_first_arg template. It failed to provide a type member for
the void specialization. With this fix, it is possible to have a handler
that has no arguments.

Tested by: Added a new callback to the asio-example.cpp. Without the
template change, this caused the build to fail as expected.
After adding the template change, the build succeeds and the
example runs as expected.

Change-Id: Ib09b58c76df8cba57dc093ab37a4c1b68ea11ad3
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...

update .clang-format header inclusion order

Added the header inclusion order to the .clang-format file generated
these changes.

Change-Id: Ia31b21d7ea451cac0309828006bc17c27cbd5bd5
Signed-off-by: P

update .clang-format header inclusion order

Added the header inclusion order to the .clang-format file generated
these changes.

Change-Id: Ia31b21d7ea451cac0309828006bc17c27cbd5bd5
Signed-off-by: Patrick Venture <venture@google.com>

show more ...

Allow callback raw access to message

In some cases, the callback may care where the message came from. Allow
the callback to receive the raw sdbusplus::message along with the
automatically extracted

Allow callback raw access to message

In some cases, the callback may care where the message came from. Allow
the callback to receive the raw sdbusplus::message along with the
automatically extracted arguments.

This means that the registration mechanism as well as the callback
mechanism need to be aware of a 'message as a first parameter' situation
and behave accordingly. The registration needs to strip the message
parameter off in order to expose a correct DBus signature. The callback
mechanism needs to strip of the message parameter in order to properly
unpack the message, but add it back in before calling apply to execute
the function.

Tested: Added an example to example/asio-example.cpp and checked to see
that it builds. Was able to extract sender from message passed
into the IPMI handler.

Change-Id: I520e494d3baad34271e748465f30274353554728
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>

show more ...