History log of /openbmc/phosphor-objmgr/ (Results 126 – 150 of 311)
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
3b025e6901-Feb-2019 Andrew Geissler <geissonator@yahoo.com>

unit-test: Introduce unit tests to phosphor-objmgr

Move a function to make more testable and add a test case for it

Testing: Verified 100% test coverage in processing.cpp

Change-Id: I0a888009cfeb5

unit-test: Introduce unit tests to phosphor-objmgr

Move a function to make more testable and add a test case for it

Testing: Verified 100% test coverage in processing.cpp

Change-Id: I0a888009cfeb57bbc8ad295681bea00b79f2a23d
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>

show more ...

12025cdc13-Feb-2019 Patrick Venture <venture@google.com>

build: pkg anti-pattern: use defaults

Use the defaults in the pkg check where the default error message is
sufficient to identify which package is missing.

Change-Id: I5bacea77a8a6814bcd21a904219f9

build: pkg anti-pattern: use defaults

Use the defaults in the pkg check where the default error message is
sufficient to identify which package is missing.

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

show more ...

09be576c23-Jan-2019 Matt Spinler <spinler@us.ibm.com>

mapper: Support association property removes

When the org.openbmc.Associations.association property changes,
the change may entail removing entries from that property,
in which case association obje

mapper: Support association property removes

When the org.openbmc.Associations.association property changes,
the change may entail removing entries from that property,
in which case association objects may need to be removed.

The existing code did not support this at all, it only
supported adding new associations.

This is done with the help of the associationOwners map, to
know which previous associations an object path and service
had so that it can tell when ones go away.

As a reminder, if an org.openbmc.Associations.associations
property under /path/A looks like:

['forward', 'reverse', '/path/B'],

then the mapper will create 2 new objects - /path/A/forward
and /path/B/reverse, with xyz.openbmc_project.Association.endpoints
property values on them of ['/path/B'], and ['/path/A'], respectively.

If that associations property is then cleared, the mapper
needs to remove the objects it created, assuming there is no
other service that also has an association that requires them.

Resolves openbmc/phosphor-objmgr#16

Change-Id: I28defa831e5aefe8dd09b96c1b104fc1610471d6
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

937a232e23-Jan-2019 Matt Spinler <spinler@us.ibm.com>

mapper: Keep track of association owners

It is possible that an association object can be sourced from
multiple D-Bus services and paths, and the existing code did
not take that into account when re

mapper: Keep track of association owners

It is possible that an association object can be sourced from
multiple D-Bus services and paths, and the existing code did
not take that into account when removing assocations on
interfacesRemoved signals, which caused it to overzealously
remove association objects.

For example, both objects /path/A and /path/B can have an
org.openbmc.Associations property value such that the mapper
creates a /path/C association object. Then, when /path/A
is removed from D-Bus, the /path/C association object should
still be kept until /path/B is also gone.

The code accomplishes this be creating a new map of association
metadata called associationOwners that keeps track of
associations based on the service and path of the object that
owns the org.openbmc.Associations object. Now, when the
interfacesRemoved signal comes in for that
org.openbmc.Associations object, the code knows if there are
other owners of an association which determine if the mapper
owned association object can be removed from D-Bus or not.

Change-Id: If483e2ecd1d832b6287c2cbd67c5d23143f9ce32
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

d732287c28-Jan-2019 James Feist <james.feist@linux.intel.com>

Fix looking for objects on root path

The current code would not remove the "/" for the root
path causing a subtree or other call with path being
"/" to miss any object exposed on "/". Fix this
so th

Fix looking for objects on root path

The current code would not remove the "/" for the root
path causing a subtree or other call with path being
"/" to miss any object exposed on "/". Fix this
so that "/" is removed when it is the only character.

Tested-by: Phosphor-pid-control stopped throwing when
looking for object managers.

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

show more ...

a82779fb09-Jan-2019 Matt Spinler <spinler@us.ibm.com>

mapper: Delete unecessary parent paths on removes

When any application creates a path on D-Bus, D-Bus will
automatically create all of the parent paths if they
don't already exist with 3 interfaces

mapper: Delete unecessary parent paths on removes

When any application creates a path on D-Bus, D-Bus will
automatically create all of the parent paths if they
don't already exist with 3 interfaces -
org.freedesktop.DBus.Peer, Introspectable, and Properties.

The mapper knows about those from either an introspection
or from explictly adding them during an interfacesAdded
signal, so now it also has to delete them out of the mapper
on an interfacesRemoved signal for the path being removed.

To do this, when a path is removed, it will traverse all of its
parents and check for the case of where a parent path only has
3 interfaces on it with the same owner, and there are no other
children remaining with that owner.

For example, if /A/B/C/D/E on owner X.Y is received in the
interfacesRemoved handler, then after /A/B/C/D/E is removed
from the interfaces map it will now check to see if /A/B/C/D
is such that:
* /A/B/C/D on owner X.Y has exactly 3 interfaces
* There is no remaining path on X.Y that starts with /A/B/C/D/.

If those are met, then /A/B/C/D on path X.Y will be removed from
the interfaces map, and then the next parent /A/B/C will be checked.

As soon as a parent doesn't need to be removed, the searching
will stop.

Tested: Check that these 3 interface paths that had been created
are properly deleted, such as
/xyz/openbmc_project/logging/entry when the last error
log is removed.

Change-Id: Ia9b79e6905108a76ddd6b425c22104bd77aedb24
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

1b4a502b03-Jan-2019 Matt Spinler <spinler@us.ibm.com>

mapper: Add missing parent paths in ifaces-added

On an InterfacesAdded signal, a new path may have just been
created with 2 or more new path segments. For example /A/B/C/D
was just created and only

mapper: Add missing parent paths in ifaces-added

On an InterfacesAdded signal, a new path may have just been
created with 2 or more new path segments. For example /A/B/C/D
was just created and only /A/B exists so far. In this case, the
current code never adds /A/B/C to the mapper, so trying to call
GetObject or GetSubTree on that path would fail.

To fix that, in the signal handler, check if all of the
parent paths are already in the interface map, and add
them if they aren't. It will take a shortcut and just add
the three org.freedesktop.DBus interfaces Introspectable, Peer,
and Properties, instead of calling the D-Bus introspect method
since that is all it would find anyway.

A big usecase of this is the REST server, where people try to
do things like GET /xyz/openbmc_project/logging/entry/enumerate,
which will fail if no logs existed when the mapper started since
nothing explicitly created that exact path.

Resolves openbmc/openbmc#3450

Tested: Created /xyz/openbmc_project/logging/entry/1,
when previously only /xyz/openbmc_project/logging existed.
Verify calling GetObject and GetSubTree now work on the
/xyz/openbmc_project/logging/entry path.

Change-Id: Id24f78beef9a34245d88de25a65006745fbda992
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

8ce2ddd904-Jan-2019 Matt Spinler <spinler@us.ibm.com>

mapper: Don't stop after first GetAncestors result

After the first result was found, the code was breaking
out instead of continuing to look for other services that
also satisified the operation. T

mapper: Don't stop after first GetAncestors result

After the first result was found, the code was breaking
out instead of continuing to look for other services that
also satisified the operation. This made it so a path
would never contain results for more than 1 service.

To fix, simply remove the break statement.

Tested: Call GetAncestors on a path with an ancestor that
has multiple services and ensure they all are now
returned.

Change-Id: I6a29b7087d4e5e9763510797e0914c2f8e160495
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

47c0975529-Nov-2018 Matt Spinler <spinler@us.ibm.com>

Filter results of GetAncestors

As with GetSubTree, GetAncestors should only return the object
paths with their services and interfaces for just the services
that implement the interfaces passed into

Filter results of GetAncestors

As with GetSubTree, GetAncestors should only return the object
paths with their services and interfaces for just the services
that implement the interfaces passed into the function.

The previous code was returning all services/interfaces for an
object path that was an ancestor instead of just the services
that actually provided that interface.

Tested: Calling GetAncestors on /xyz/openbmc_project/ with
the ObjectManager interface filter would now only
return ancestors that actually had the ObjectManager
interface.

Change-Id: Ie80e78ac76a6fe9d474e6b34bc4555dca490ac51
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

6a39e8c713-Nov-2018 Matt Spinler <spinler@us.ibm.com>

mapper: Don't fail on some empty results

To preserve the behavior of the original mapper, don't
fail the GetSubTree, GetSubTreePaths, and GetAncestors
calls if the results are empty, instead only fa

mapper: Don't fail on some empty results

To preserve the behavior of the original mapper, don't
fail the GetSubTree, GetSubTreePaths, and GetAncestors
calls if the results are empty, instead only fail if
the passed in object path isn't valid.

This is particularly important to preserve the REST API
that requires this different behavior between empty
results and bad paths.

Change-Id: I7e808a5613ed66cba4ea1a179a880e5c3f597f2a
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

06e5d2fe13-Nov-2018 Matt Spinler <spinler@us.ibm.com>

bindings: Skip the default ifaces on enumerate

The C++ mapper will now return D-Bus object paths that only
contain the 3 default D-Bus interfaces:
* org.freedesktop.DBus.Introspectable
* org.freedes

bindings: Skip the default ifaces on enumerate

The C++ mapper will now return D-Bus object paths that only
contain the 3 default D-Bus interfaces:
* org.freedesktop.DBus.Introspectable
* org.freedesktop.DBus.Peer
* org.freedesktop.DBus.Properties

Whereas before it would filter out these paths.

As these paths aren't explicitly hosted by a service,
trying to do a GetAll method to read their properties,
which would occur during an enumerate REST operation,
would fail.

The fix is to skip trying to read properties on these
interfaces.

Change-Id: I9b306a4fbefa78c60f739c1351cd32ee2c36c234
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

d4dd96a012-Nov-2018 Ed Tanous <ed.tanous@intel.com>

Remove interface filter

There are a number of cases where the interface filter causes some
confusion. Not exposing org.freedesktop.DBus.ObjectManager interfaces
caused some confusion around collect

Remove interface filter

There are a number of cases where the interface filter causes some
confusion. Not exposing org.freedesktop.DBus.ObjectManager interfaces
caused some confusion around collections of objects, and the ability to
search for sensors. Also, objects where the "parent" object has no
useful interfaces leads to some question about how things like
GetSubTree should behave in this condition.

This patchset removes the interface filter alltogether. The only
negatives should be a slightly increased memory usage, and extra
interface support in mapperx.

On a positive, it makes it a lot less likely to see bugs where the
blacklists are concerned.

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

show more ...

50232cd412-Nov-2018 Ed Tanous <ed.tanous@intel.com>

Mapper: Remove unused ObjectManager usage

See comment for why the code was kept around. It looks like I
misunderstood associations, so that code wasn't required after all.
Clean up the ununsed code

Mapper: Remove unused ObjectManager usage

See comment for why the code was kept around. It looks like I
misunderstood associations, so that code wasn't required after all.
Clean up the ununsed code..

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

show more ...

153494e007-Nov-2018 Matt Spinler <spinler@us.ibm.com>

mapper: Don't return the input path in GetSubTree

In both GetSubTree and GetSubTreePaths, don't return
the input path as a result. This matches the behavior
of the original mapper.

Change-Id: Ib4b

mapper: Don't return the input path in GetSubTree

In both GetSubTree and GetSubTreePaths, don't return
the input path as a result. This matches the behavior
of the original mapper.

Change-Id: Ib4bab71a6001e9a18ab2565b0e2d708b034f8c44
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

af1aa75615-Nov-2018 Brad Bishop <bradleyb@fuzziesquirrel.com>

maintainers: Update committers

Ed wrote the c++ mapper. Matt has been hacking on the mapper a lot
lately as well. It makes sense that they have committer access.

Change-Id: I48cb7e2c32324f395136c

maintainers: Update committers

Ed wrote the c++ mapper. Matt has been hacking on the mapper a lot
lately as well. It makes sense that they have committer access.

Change-Id: I48cb7e2c32324f395136c4adbdfbcdcc41da894a
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...

5935b1e330-Oct-2018 Ed Tanous <ed.tanous@intel.com>

mapper: Fix GetSubTree bug in the c++ mapper

In cases where multiple daemons expose the same interface, there was a
bug where, if an interface filter was applied, only the first found
daemon would b

mapper: Fix GetSubTree bug in the c++ mapper

In cases where multiple daemons expose the same interface, there was a
bug where, if an interface filter was applied, only the first found
daemon would be returned. This resulted in sub-optimal behavior when
searching for things like ObjectManager, that might exist in a lot of
daemons.

Tested By: Before Patch: root@wolfpass:/# dbus-send --system
--print-reply --dest=xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/object_mapper
xyz.openbmc_project.ObjectMapper.GetSubTree string:"/" int32:1
array:string:org.freedesktop.DBus.ObjectManager

Returns 1 entry

After Patch:

root@wolfpass:/# dbus-send --system --print-reply
--dest=xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/object_mapper
xyz.openbmc_project.ObjectMapper.GetSubTree string:"/" int32:1
array:string:org.freedesktop.DBus.ObjectManager

returns 12 entries

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

show more ...

0570c69423-Oct-2018 Matthew Barth <msbarth@us.ibm.com>

Check for boost headers used

The AX_BOOST_BASE macro checks a set of directory locations for the
availability of boost which can cause an issue when one is found and
its below the specified version.

Check for boost headers used

The AX_BOOST_BASE macro checks a set of directory locations for the
availability of boost which can cause an issue when one is found and
its below the specified version. (A version number is required when
using the AX_BOOST_BASE macro and was chosen to match the boost version
within the SDK.) This fix replaces the use of the AX_BOOST_BASE macro
with checking for the boost headers used.

Resolves: openbmc/openbmc#3411

Change-Id: Ia24120e55f77576a45f6f85988328f7127ea00c7
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>

show more ...

365dee3219-Oct-2018 Brad Bishop <bradleyb@fuzziesquirrel.com>

python-mapper: Switch to dbus service whitelist

Use dbus service/busname filtering to match the c++ mapper. This
facilitates an easy transition to c++ mapper.

Set service-namespace as a required p

python-mapper: Switch to dbus service whitelist

Use dbus service/busname filtering to match the c++ mapper. This
facilitates an easy transition to c++ mapper.

Set service-namespace as a required parameter.
Set path-namespace as an optional parameter.

Change-Id: I6b16622ee1cb354030a82e7b9d412235933c2d39
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...

cfe3e44222-Oct-2018 Brad Bishop <bradleyb@fuzziesquirrel.com>

python-mapper: Accept service-namespaces

The c++ mapper implements a dbus service namespace whitelist instead of
a path namespace whitelist. A service namespace whitelist significantly
reduces the

python-mapper: Accept service-namespaces

The c++ mapper implements a dbus service namespace whitelist instead of
a path namespace whitelist. A service namespace whitelist significantly
reduces the amount of introspection required by the mapper as compared
to path namespaces. Update the python mapper to accept the new command
line arguments.

This is entirely throw-away code to reduce corequisites as users
(OpenBMC) transition to the c++ mapper. As such, no logic is
implemented behind the new command line options.

Change-Id: Ic952e85dbd44e850059e67a3675ddbf1dd2f15b1
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...

db27894215-Oct-2018 Matthew Barth <msbarth@us.ibm.com>

Add configure check for boost library

605206314f added use of flat_map/set and some boost algorithm.

Change-Id: I63465542fb3b9c02e2890ff52ebdd3fd0e4c6e01
Signed-off-by: Matthew Barth <msbarth@us.ib

Add configure check for boost library

605206314f added use of flat_map/set and some boost algorithm.

Change-Id: I63465542fb3b9c02e2890ff52ebdd3fd0e4c6e01
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...

a493615203-Oct-2018 Vernon Mauery <vernon.mauery@linux.intel.com>

Compile with c++17

Unlock new language and feature support.

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

ea6516c425-Sep-2018 Matt Spinler <spinler@us.ibm.com>

Don't return the input path in GetAncestors

If '/A/B/C' is passed in as the path argument into GetAncestors,
don't return /A/B/C, but only its actual ancestors /A and /A/B.

Change-Id: I8dde80fa2ae5

Don't return the input path in GetAncestors

If '/A/B/C' is passed in as the path argument into GetAncestors,
don't return /A/B/C, but only its actual ancestors /A and /A/B.

Change-Id: I8dde80fa2ae5fad26c93be5fda5cfda9ff1b77d8
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

59cbf34624-Sep-2018 Matt Spinler <spinler@us.ibm.com>

mapper: Handle the expected GetSubTreePaths fails

The 'mapper subtree-remove' command calls GetSubTreePaths
when it starts up to check if a certain interface currently
exists on a certain path. If

mapper: Handle the expected GetSubTreePaths fails

The 'mapper subtree-remove' command calls GetSubTreePaths
when it starts up to check if a certain interface currently
exists on a certain path. If that interface does not exist
on that path, the current ObjectMapper implementation would
just return an empty list, and the program would exit.

The new ObjectMapper implementation will fail the GetSubTreePaths
call in that case, causing an ENXIO inside of sd_event_loop().

This commit checks for the ENXIO and then just exits immediately
with a return code of 0, as this is the case where the interface
had been removed before the program was started.

Change-Id: Iaeb908ee9a0db8952ef77cc63675e0f7abe3b6c7
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

f9a1718119-Sep-2018 Matt Spinler <spinler@us.ibm.com>

Add mapperx to .gitignore

Change-Id: I67b3b1194aaa5eb174c522220d637bc231f883f1
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

aecabe8619-Sep-2018 Matt Spinler <spinler@us.ibm.com>

Remove good path trace statements

These were good for debug, but shouldn't be necessary anymore.

Change-Id: I0a2947dbd95da2532b2689329020519c39a21f6e
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

12345678910>>...13