David Herrmann
2d5c8a2756
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.
systemd - System and Service Manager
Details
- General information about systemd can be found in the systemd Wiki
- Information about build requirements are provided in the README file