| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Real D-Bus error message will not be known through
boost::system::error_code and hence requires message::message
to be forwarded to the caller, through which any D-Bus error
message can be read from the sd_bus_error of the message::message.
Tested:
Added the template for the same, and cross verified with
async_method_call, of which handler will accept both error_code
& message::message as argument
Change-Id: I7ecace1fb880a303dd487fa9de85c043db3413f8
Signed-off-by: Richard Marian Thomaiyar <richard.marian.thomaiyar@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
async_result is required to be able to support boost 1.70. This commit
moves us to it.
Tested:
Compiled. Changes are non-functional, and simply renamed in newer
versions of asio.
Change-Id: I46728dc146c4c49eff7907c6aa8bc1525eca5cc2
Signed-off-by: Ed Tanous <ed.tanous@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InterfacesAdded signal itself will send out all propety
details and it's values during start-up of a D-Bus daemon service.
Sending properties changed signal confuses the signal handler
as it can't differentiate between service restart or real
property change event. Exposing a way to skip sending
properties changed signal during initialize (to avoid
breaking any old one).
Tested-by:
1. Verified that when initialize(true) is called, properties
changed signal are not sent out from D-Bus daemon
2. Still old method works fine.
Change-Id: Ib436ea9313b08623d931c58b11a770081511ab72
Signed-off-by: Richard Marian Thomaiyar <richard.marian.thomaiyar@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
The underlying sd_event checks to see that the file descriptor is good
before calling close, so if the sd_event_wrapper closes the descriptor
first, sd_event calls assert(). The release() mechanism allows the
sd_event to close out the descriptor on its own.
Change-Id: Icb8ca5ba909478361a90253713a425256556d140
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Different capabilities are supported depending on if an interface
has been initialized (e.g. register_property is only available before
initialization and set_property is only available after).
This change adds a method to check if an interface has been initialized
to help determine which capabilities are currently supported.
Tested: Ran a module that uses register_property and set_property based
on this return value and confirmed that the properties are set
accordingly.
Change-Id: Iac39887f5d92981a316d1046f2f3d3ab71d15878
Signed-off-by: Jason M. Bills <jason.m.bills@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For asio based registration, ObjectManager's are created
under "/" folder. This makes dynamic detection difficult based
on the service root object path. Updated library to skip
ObjectManager creation, which can be created separately
by the needed daemon under the root object base path
This is needed, as dynamic detection of service name
can be performed on org.freedeskop.DBus.ObjectManager interface
when the root object doesn't have any interfaces.
Unit-test:
1. Verified it is compiling, and compatibile with existing code
2. Verified that ObjectManager is under the needed base path
when argument passed from service daemon.
3. Able to find service name using GetObject under objectMapper,
when service daemon, doens't have any other interface in root
base path other than org.freedesktop.DBus.Manager
Change-Id: Ie1ddf62df0df3849fc761995813c97872d96eb33
Signed-off-by: Richard Marian Thomaiyar <richard.marian.thomaiyar@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set property has to send out signal only when there is
change in the property and skipped when there is no change
but still must return true for the set method accordingly
Unit test:
Using busctl monitor match rule, monitored the properties changed
of sensors (which uses asio logic) and verified by updating
the value with same & different one, and observed both the return
(success) and the properties changed signal generated only when
there is changed in the property value as expected.
Change-Id: I79be5b29f496109c19e415cdcfff89af76693de5
Signed-off-by: Richard Marian Thomaiyar <richard.marian.thomaiyar@linux.intel.com>
|
| |
|
|
|
|
|
|
| |
The documentation says that the default bus calls are the ones to use
instead of the open bus calls to reduce resources.
Change-Id: I719494adf2e97e94bb5a9925064cda6cfdd28047
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
Signaling a property in an non-initialized interface
causes a segfault.
Testedy-by: Verified segfault went away.
Change-Id: Ib48510e761fb69667040351056853a470c5a9a9f
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
Setting the same value causes egregious properties changed
events. Return 0 if the user attempts to do this.
Tested-by: used dbus-monitor and noticed reduced traffic
when using set_property
Change-Id: I2643a01fd0e1cc1e0c0ed407056f0e3cd898865b
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
The return value from sd_bus_error_set is always a negative error value
mapping to the provided name. We should use this value instead of always
returning -EINVAL.
Change-Id: I102c7a0b306db873d44e9c1b7cbd9cc146ffe29c
Signed-off-by: William A. Kennington III <wak@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sd_bus_error_set_const takes pointers to c-style strings as arguments
which populate its name and message. This function does not take any
ownership of the name or message, requiring the to live beyond the
lifetime of the error. Since we are destroying the error object as soon
as we leave the catch blocks, we are destroying the strings passed to
the sd_bus_error. This violates the lifetime guarantee.
Instead, use the sd_bus_error_set method which copies the strings. We
know that the callers of these callbacks free the errors by inspecting
the libsystemd code.
Tested:
Run through unit tests which still pass
Change-Id: Ifa1533fc4c41db070f5bf2901581e9f5680cabfc
Signed-off-by: William A. Kennington III <wak@google.com>
|
| |
|
|
|
|
|
|
| |
If the handler throws in its error path, then this would cause a memory
leak (assuming that the executer is catching exceptions).
Change-Id: I44f0feaa7d317a7d8a23bc65a3d9cf6078539f44
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
Oenbmc documentation specifies a left alignment for pointers. Our
current format tries to left align if neither alignment is strictly
followed, but will allow right aligned files to exist. Lets make this
more strict so that all of our files are consistent.
Change-Id: I3a50043d28a9c25d0cf1ffb752800d05eb7615e1
Signed-off-by: William A. Kennington III <wak@google.com>
|
| |
|
|
|
|
|
| |
To better match the defined openbmc style.
Change-Id: I68cda43857768bae4c904c367942cb1f0efa3e0c
Signed-off-by: Patrick Venture <venture@google.com>
|
| |
|
|
|
|
|
|
| |
Added the header inclusion order to the .clang-format file generated
these changes.
Change-Id: Ia31b21d7ea451cac0309828006bc17c27cbd5bd5
Signed-off-by: Patrick Venture <venture@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
Spelling errors found using github.com/lucasdemarchi/codespell
A tool to fix common misspellings.
This tool is licensed under GNU General Public License, version 2.
Change-Id: I99921bb9541fb37cb8999337a72d540494fbb4d7
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From the docs, sd_bus_process should be called until no progress
can be made. When progress is made, a positive integer is returned.
Add read_immediate to bypass setting up the fd watch when process_discard
returns a positive value.
Tested-by: Had C++ Mapper and Entity-Manager call each-other at the same
time and noticed no longer timed out.
Change-Id: Icab11743c6c5e1486b353fce1d5e3898f2d3f533
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
| |
Asio was missing these signals, this was discovered while writing
the CPP mapper.
Tested: Restarted the fru device and watched using dbus-mointor.
Also devices were able to be found by the mapper after boot.
Change-Id: I9d6e9c6087e36a3b79853432f46cc3942d317340
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add properties server similar to boost-dbus that allows
for creating dbus interfaces during runtime. This adds
support for creating methods and get / set properties.
Get / set property callbacks are stored in flat_maps of
std::function allowing custom get / set functions. Methods
are also stored in this way allowing for creating of interfaces
without using any yaml. There is one C level callback for properties
get, properties set, and method calls that lookup the correct
std::function in the flat_map to call.
Tested: Ran asio-example on bmc, and updated fru-device.
Change-Id: I19881049f4307fe9c68f78df8854f14afdd6c362
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
|
|
Add an async connection and example of usage. This
connection inherits the bus object and allows async
method calls using boost asio. Most of these concepts
are from boost-dbus.
Change-Id: I33b5349d543c9ff4b6ee1ce15346c709c052e1ae
Tested: Compiled and ran asio-example on bmc.
Signed-off-by: James Feist <james.feist@linux.intel.com>
|
