sd-bus: fix path of object-manager signals #641
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Each signal of the ObjectManager interface carries the path of the object in question as an argument. Therefore, a caller will deduce the object this signal is generated for, by parsing the _argument_. A caller will *not* use the object-path of the message itself (i.e., message->path). This is done on purpose, so the caller can rely on message->path to be the path of the actual object-manager that generated this signal, instead of the path of the object that triggered this signal. This commit fixes all InterfacesAdded/Removed signals to use the path of the closest object-manager as message->path. 'closest' in this case means closest parent with at least one object-manager registered. This fix raises the question what happens if we stack object-managers in a hierarchy. Two implementations are possible: First, we report each object only on the nearest object-manager. Second, we report it on each parent object-manager. This patch chooses the former. This is compatible with other existing ObjectManager implementations, which are required to call GetManagedObjects() recursively on each object they find, which implements the ObjectManager interface.
|
Looks fine to me otherwise! |
|
Both fixed and pushed. Thanks! |
|
@dvdhrm for the sake of completeness, can you mention the git id of the git commit you ultimately fixed this with? |
|
Ah, nvm, here it is: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Each signal of the ObjectManager interface carries the path of the object
in question as an argument. Therefore, a caller will deduce the object
this signal is generated for, by parsing the argument. A caller will
not use the object-path of the message itself (i.e., message->path).
This is done on purpose, so the caller can rely on message->path to be
the path of the actual object-manager that generated this signal, instead
of the path of the object that triggered this signal.
This commit fixes all InterfacesAdded/Removed signals to use the path of
the closest object-manager as message->path. 'closest' in this case means
closest parent with at least one object-manager registered.
This fix raises the question what happens if we stack object-managers in
a hierarchy. Two implementations are possible: First, we report each
object only on the nearest object-manager. Second, we report it on each
parent object-manager. This patch chooses the former. This is compatible
with other existing ObjectManager implementations, which are required to
call GetManagedObjects() recursively on each object they find, which
implements the ObjectManager interface.