We can dispose the manager before loading the factories:
NetworkManager[20214]: <error> [1439391976.738579] [nm-bus-manager.c:764] nm_bus_manager_start_service(): Could not acquire the NetworkManager service as it is already taken.
NetworkManager[20214]: <error> [1439391976.738617] [main.c:424] main(): failed to start the dbus service.
NetworkManager[20214]: nm_device_factory_manager_for_each_factory: assertion 'factories_by_link' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x5a5028 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd750) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4a738c3 in g_logv (log_domain=0x5a5028 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd750) at gmessages.c:1046
#1 0x00007ffff4a73a3f in g_log (log_domain=log_domain@entry=0x5a5028 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff4ae173d "%s: assertion '%s' failed")
at gmessages.c:1079
#2 0x00007ffff4a73a79 in g_return_if_fail_warning (log_domain=log_domain@entry=0x5a5028 "NetworkManager", pretty_function=pretty_function@entry=0x5a5420 <__FUNCTION__.26921> "nm_device_factory_manager_for_each_factory", expression=expression@entry=0x5a4f25 "factories_by_link") at gmessages.c:1088
#3 0x00000000004704e4 in nm_device_factory_manager_for_each_factory (callback=callback@entry=0x4d29a0 <_deinit_device_factory>, user_data=user_data@entry=0x8802b0) at devices/nm-device-factory.c:306
#4 0x00000000004d2927 in dispose (object=0x8802b0 [NMManager]) at nm-manager.c:5086
#5 0x00007ffff4d6ea82 in g_object_unref (_object=0x8802b0) at gobject.c:3133
#6 0x00000000004459f6 in main (argc=1, argv=0x7fffffffda88) at main.c:468
(gdb)
Future patches will create devices long before they are backed by
kernel resources, so we need to split NMDevice object creation from
actual setup based on the backing resources.
This patch combines the NMDeviceFactory's new_link() and
create_virtual_device_for_connection() class methods into a single
create_device() method that simply creates an unrealized NMDevice
object; this method is not expected to fail unless the device is
supposed to be ignored. This also means that the NMDevice
'platform-device' property is removed, because a platform link
object may not be available at NMDevice object creation time.
After the device is created, it is then "realized" at some later
time from a platform link (for existing/hardware devices via the
realize() method) or from an NMConnection (for newly created software
devices via the create_and_realize() NMDeviceClass methods).
https://bugzilla.gnome.org/show_bug.cgi?id=737458
nm_device_factory_manager_find_factory_for_link_type()
easily can see a link-type NM_LINK_TYPE_UNKNOWN because
there are many link types that NetworkManager cannot detect.
Just return NULL early.
Fixes: 71bde20c30
Instead of hacky stuff in the Manager, let plugins themselves indicate
which links should be ignored (because they are really child links that
are controlled by a different device that the plugin handles).
Instead of having a bunch of logic in the Manager for determining the
VLAN and Infiniband virtual interface names, move the type-specific
logic into the plugins themselves.
Instead of looping over all plugins and asking each plugin whether it
can handle a link or a connection, have them advertise the link and
connection types they support, and use that when creating new devices.
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
In preparation for internal device types exposing factories too, it's
easier to have the device type that the factory creates be returned
by the factory object instead of the plugin, because internal device
types don't have plugins.
This requires that we create the factory objects earlier, which
further requires that any operations that trigger signals must be
moved out of each factory's construction path to a separate start()
function.
Instead of having a GObject property and a factory function to get
the plugin's device type, just use the factory function, since it
always has to be around.
In preparation for making WWAN and Bluetooth plugins, rework
the device plugin interface to meet those plugins' needs and
port WiMAX over in the process.
