asio: Explicitly discard return value for spawn

otherwise we get
```
error: ignoring returned value of type ‘boost::asio::deferred_async_operation<...
```

Change-Id: I8929539ee46f9791e69d0ea3558ff6

asio: Explicitly discard return value for spawn

otherwise we get
```
error: ignoring returned value of type ‘boost::asio::deferred_async_operation<...
```

Change-Id: I8929539ee46f9791e69d0ea3558ff60c5d2b5a6d
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

break out boost coroutines async_send

async_send is a method that was attempted to be shared between coroutine
and non-coroutine cases. Unfortunately to have this code sharing
requires a very expen

break out boost coroutines async_send

async_send is a method that was attempted to be shared between coroutine
and non-coroutine cases. Unfortunately to have this code sharing
requires a very expensive template, boost::asio::initiate. While this
template is great for generalizing, it results in a template
instantiation per call site, which doesn't scale well at build time in
things like bmcweb, where we have 400+ async_method_call sites.

This commit breaks out async_send into async_send and async_send_yield,
which allows using concrete callback and return types, thus avoiding
the multiple template instantiations.

Tested: ClangBuildAnalyzer shows that this template is no longer one of
the longest to instantiate.

Change-Id: Ic8f226e5be71f05c5f5dcb73eb51e6094dc704eb
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

boost version 1.86 support

Added fix for boost::asio::spawn overload issue reported similar
to chriskohlhoff/asio#1524. This error reported by CI build during
boost version bump.

Error details

'''

boost version 1.86 support

Added fix for boost::asio::spawn overload issue reported similar
to chriskohlhoff/asio#1524. This error reported by CI build during
boost version bump.

Error details

'''
../example/asio-example.cpp:375:23:
error: call of overloaded ‘spawn(boost::asio::io_context&, client()::<lambda(boost::asio::yield_context)>)’ is ambiguous
375 | boost::asio::spawn(io, [conn](boost::asio::yield_context yield) {
| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
376 | do_start_async_method_call_one(conn, yield);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
377 | });
| ~~
In file included from /usr/local/include/boost/asio/spawn.hpp:871,
from ../example/asio-example.cpp:2:
'''

Proposed fix is to explicitly specify the completion token.

Tested: verified build

Change-Id: I5ec16f8f33c617a6abc823abf75b765c0d031141
Signed-off-by: Jayanth Othayoth <ojayanth@gmail.com>

show more ...

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

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

show more ...

timer: deprecate phosphor namespace

"phosphor" is a namespace used in some OpenBMC repositories but has
only one usage in sdbusplus and the class is not very OpenBMC-specific.

Move the Timer class

timer: deprecate phosphor namespace

"phosphor" is a namespace used in some OpenBMC repositories but has
only one usage in sdbusplus and the class is not very OpenBMC-specific.

Move the Timer class into the sdbusplus namespace and mark
'phosphor::Timer' as a deprecated alias.

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

show more ...

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

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

show more ...

Catch the correct sdbusplus exception

sdbusplus::exception::SdBusError is intended to be internal to the
sdbusplus library [1] and not depended on by client code:

['SdBusError'] was always inte

Catch the correct sdbusplus exception

sdbusplus::exception::SdBusError is intended to be internal to the
sdbusplus library [1] and not depended on by client code:

['SdBusError'] was always intended to be internal to sdbusplus (in
fact, it inherits from an error called 'internal_error')

and `include/sdbusplus/exception.hpp`:

/** Exception for when an underlying sd_bus method call fails. */
class SdBusError final : public internal_exception

(Only) catching and handling `sdbusplus::exception::SdBusError` may lead
to some sdbusplus exceptions being unhandled and thus propagating [1]:

Quite likely, by catching this exception, you are missing other
exceptions that sdbusplus can throw.

The correct general exception seems to be
`sdbusplus::exception::exception`.

Tested: Executed the affected `asio-example` with and without this
change and verified the output was the same (except for differences in
the order of printed messages, which seems to vary from invocation to
another also without the change).

[1] The message "sdbusplus exception type SdBusError" on the sdbusplus mailing list: https://lore.kernel.org/openbmc/YTDvfIn4Z05mGdCx@heinlein/

Change-Id: I5cda83c593730f6c0ce5735fb7c46d43f2066c9d
Signed-off-by: Hannu Lounento <hannu.lounento@vaisala.com>

show more ...

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

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

show more ...

Use more specific includes

We shouldn't be including all of asio, just the parts we need.

Change-Id: I15f5ffa40311644df98fcb9164cac529a423d232
Signed-off-by: Ed Tanous <edtanous@google.com>

Remove static from inline variables

These do not need to be static in this context. They are used to
construct a message and that's it, constexpr is better.

At the same time, change the auto on de

Remove static from inline variables

These do not need to be static in this context. They are used to
construct a message and that's it, constexpr is better.

At the same time, change the auto on depth to int32_t, because that is
the correct API.

Change-Id: Ie2fc84eb2fee13af4c898854b822d8dbd190f5a4
Signed-off-by: Ed Tanous <edtanous@google.com>

show more ...

Clean up ASIO set-property callback code

This reverts commit ce62764d6c0a72ec88eb433e1afd05b751225971, which
introduced inconsistent semantics for the underlying ASIO set handler
functions. The "ext

Clean up ASIO set-property callback code

This reverts commit ce62764d6c0a72ec88eb433e1afd05b751225971, which
introduced inconsistent semantics for the underlying ASIO set handler
functions. The "external" `call` case expected the handler to return an
integer error code, while the "internal" `set` case expected the handler
to return a boolean status.

This also does a small refactor on the two similar `call` and `set`
functions to deduplicate, and adds ASIO.md to document the expected
semantics of the ASIO handlers.

The vast majority of user code in OpenBMC is still returning integers
from the callbacks (0/1/-1), but in most cases 0 was used to mean
failure, and 1 was used to mean success, so formalizing that the
callback should return a boolean value will not break things.

Tested: With accompanying dbus-sensors change
I05c41318954d5d1549752c5ef2c227f3f22a45d3, using steps in that commit
msg.

Signed-off-by: Jonathan Doman <jonathan.doman@intel.com>
Change-Id: Ic3a36027fa95a77469439b296a1497634cfe030f

show more ...

clang-format: update whitespace penalty

clang-format-15 seems to end up with a slightly different whitespace
break than clang-format-14 did. Tweak the PenaltyBreakAssignment
to favor not breaking a

clang-format: update whitespace penalty

clang-format-15 seems to end up with a slightly different whitespace
break than clang-format-14 did. Tweak the PenaltyBreakAssignment
to favor not breaking as often, which allows the two to be more
consistent.

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

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

catch exceptions as const

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

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

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

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

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