Branch f9b1bc16e9e691ab89caf883f33d94be72364671 added bluetooth NAP support. A NAP connection is of connection.type "bluetooth", but it also has a "bridge" setting. Also, it is primarily handled by NMDeviceBridge and NMBridgeDeviceFactory (with help from NMBluezManager). However, don't let nm_connection_get_connection_type() and nm_connnection_is_type() lie about what the connection.type is. The type is "bluetooth" for most purposes -- at least, as far as the client is concerned (and the public API of libnm). This restores previous API behavior, where nm_connection_get_connection_type() and nm_connection_is_type() would be simple accessors to the "connection.type" property. Only a few places care about the bridge aspect, and those places need special treatment. For example NMDeviceBridge needs to be fully aware that it can handle bluetooth NAP connection. That is nothing new: if you handle a connection of any type, you must know which fields matter and what they mean. It's not enough that nm_connection_get_connection_type() for bluetooth NAP connectins is claiming to be a bridge. Counter examples, where the original behavior is right: src/nm-manager.c- g_set_error (error, src/nm-manager.c- NM_MANAGER_ERROR, src/nm-manager.c- NM_MANAGER_ERROR_FAILED, src/nm-manager.c- "NetworkManager plugin for '%s' unavailable", src/nm-manager.c: nm_connection_get_connection_type (connection)); the correct message is: "no bluetooth plugin available", not "bridge". src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: if ( ( nm_connection_is_type (connection, NM_SETTING_WIRED_SETTING_NAME) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: && !nm_connection_get_setting_pppoe (connection)) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_VLAN_SETTING_NAME) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_WIRELESS_SETTING_NAME) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_INFINIBAND_SETTING_NAME) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BOND_SETTING_NAME) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_TEAM_SETTING_NAME) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BRIDGE_SETTING_NAME)) src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c- return TRUE; the correct behavior is for ifcfg-rh plugin to reject bluetooth NAP connections, not proceed and store it.
This speeds up the initial object tree load significantly. Also, it reduces the object management complexity by shifting the duties to GDBusObjectManager. The lifetime of all NMObjects is now managed by the NMClient via the object manager. The NMClient creates the NMObjects for GDBus objects, triggers the initialization and serves as an object registry (replaces the nm-cache). The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the object creation, removal and property changes. It takes care of the property changes so that we don't have to and lets us always see a consistent object state. Thus at the time we learn of a new object we already know its properties. The NMObject unfortunately can't be made synchronously initializable as the NMRemoteConnection's settings are not managed with standard o.fd.DBus Properties and ObjectManager APIs and thus are not known to the ObjectManager. Thus most of the asynchronous object property changing code in nm-object.c is preserved. The objects notify the properties that reference them of their initialization in from their init_finish() methods, thus the asynchronously created objects are not allowed to fail creation (or the dependees would wait forever). Not a problem -- if a connection can't get its Settings, it's either invisible or being removed (presumably we'd learn of the removal from the object manager soon). The NMObjects can't be created by the object manager itself, since we can't determine the resulting object type in proxy_type() yet (we can't tell from the name and can't access the interface list). Therefore the GDBusObject is coupled with a NMObject later on. Lastly, now that all the objects are managed by the object manager, the NMRemoteSettings and NMManager go away when the daemon is stopped. The complexity of dealing with calls to NMClient that would require any of the resources that these objects manage (connection or device lists, etc.) had to be moved to NMClient. The bright side is that his allows for removal all of the daemon presence tracking from NMObject.
On D-Bus level, string (s) or object paths (o) cannot be NULL. Thus, whenver server exposes such an object, it gets automatically coerced to "" or "/", respectively. On client side, libnm should coerce certain properties back, for which "" is just not a sensible value. For example, an empty NM_DEVICE_ETHERNET_HW_ADDRESS should be instead exposed as NULL. Technically, this is an API change. However, all users were well advised to expect both NULL and "" as possible return values and handle them accordingly.
sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
- All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
The localization headers are now included via "nm-default.h". Also fixes several places, where we wrongly included <glib/gi18n-lib.h> instead of <glib/gi18n.h>. For example under "clients/" directory.
Rather than randomly including one or more of <glib.h>, <glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include "nm-glib-compat.h" most of the time), rename nm-glib-compat.h to nm-glib.h, include <gio/gio.h> from there, and then change all .c files in NM to include "nm-glib.h" rather than including the glib headers directly. (Public headers files still have to include the real glib headers, since nm-glib.h isn't installed...) Also, remove glib includes from header files that are already including a base object header file (which must itself already include the glib headers).
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _() will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than "gettext (string)" (which will use the program's default domain, which works fine for programs in the NetworkManager tree, but not for external users). Likewise, we need to call bindtextdomain() so that gettext can find the translations if the library is installed in a different prefix from the program using it (and bind_textdomain_codeset(), so it will know the translations are in UTF-8 even if the locale isn't). (The fact that no one noticed this was broken before is because the libraries didn't really start returning useful translated strings much until 0.9.10, and none of the out-of-tree clients have been updated to actually show those strings to users yet.)
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.)