NMExportedObject is the center of every D-Bus exported object in
NetworkManager's core. It makes sense to optimize it.
Transform the GSList of interfaces to be a array. The array is still
allocated via the slice allocator (as we expect that there are only few
types in the list). This saves the overhead to allocate a GSList item
for each entry.
Another advantage is that the interfaces list is now strongly typed
instead of an opaque data pointer.
NMExportedObject now derives from GDBusObjectSkeleton, which is what
GDBusObjectManagerServer wants. The main GDBusConnection and each
private server connection now gets a new GDBusObjectManagerServer,
and exported objects are registered with that instead of individually
exporting each GDBusInterfaceSkeleton.
Previously exported objects were not referenced by the BusManager,
but instead removed from the exports hash via weak references. The
GDBusObjectManagerServer instead references exported objects, which
can make them live much longer than they did before.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Previously most objects were implicitly unexported when they were
destroyed, but since refcounts may make the object live longer than
intended, we should explicitly unexport them when they should no
longer be present on the bus.
This means we can assume that objects will always be un-exported
already when they are destroyed, *except* when quitting where most
objects will live until exit because NM leaves interfaces up and
running on quit.
Exporting the object already in the *_init() function will later
break because the object is not yet fully initialized at that point.
Add a convenient flag so that the NMExportedObject parent implementation
automatically can export itself. This saves the derived class from
overwriting the constructed() method.
Also add an assertion to catch such bugs.
- Also if the target object is the NMManager instance itself,
re-fetch the manager via nm_bus_manager_get_registered_object().
This way, we only set the property on the manager, if
it's also exported according to the bus-manager. Also,
we don't treat the manager instance special.
- Move fetching the object (nm_bus_manager_get_registered_object())
from do_set_property_check() to prop_set_auth_done_cb(). Otherwise,
we fetch the object first, but there is no guarantee that the object
is still exported after the asynchronous authentication succeeds.
Previously, nm_bus_manager_register_object() would take various D-Bus
skeleton objects that were associated with one NMExportedObject.
This was confusing, in that these skeleton objects are all for the
same NMObject but correspond to different D-Bus interfaces.
Also, setting the D-Bus property "Managed" of a Device is broken
because we might retrieve the wrong skeleton.
Now, the NMBusManager has a reference to the exported object directly.
The skeleton interface instances instead are now exposed by the NMExportedObject.
Port NMExportedObject to gdbus, and make
nm_exported_object_class_add_interface() deal with generating D-Bus
skeleton objects and attaching signal handlers and property bindings
as needed to properly handle methods, signals, and properties.
Move D-Bus export/unexport handling into NMExportedObject and remove
type-specific export/get_path methods (export paths are now specified
at the class level, and NMExportedObject handles the counters for all
exported types automatically).
Since all exportable objects now use the same get_path() method, we
can also add some helper methods to simplify get_property()
implementations for object-path and object-path-array properties.
Add NMExportedObject, make it the base class of all D-Bus-exported
types, and move the nm-properties-changed-signal logic into it. (Also,
make NMSettings use the same properties-changed code as everything
else, which it was not previously doing, presumably for historical
reasons).
(This is mostly just shuffling code around at this point, but
NMExportedObject will be more important in the gdbus port, since
gdbus-codegen doesn't do a very good job of supporting objects that
export multiple interfaces [as each NMDevice subclass does, for
example], so we will need more glue/helper code in NMExportedObject
then.)
