These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
System settings still links to libnm-glib, which also contains
an NMDeviceWimax class. We don't care about the libnm-glib
class, so link the wimax bits first to ensure they are the ones
used.
This issue will go away when user settings is removed in the
near future.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
Some stuff we build (the DHCP manager) gets built independently
so that we can use it for unit tests. For that, we need to build
the logging bits separately too, since the independent DHCP
library can't use them if they are embedded in NM.
After the DUN branch merge (I think?) a number of NM_IS_MODEM
calls were left around which now always return FALSE since
NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore.
But we still need generic "is this a modem subclass" checks in
a few places, so add a modem base class that both the GSM and
CDMA device classes inherit from and use that.
Plus, we want to consolidate a ton of the common code in
nm-device-gsm.c and nm-device-cdma.c into the base class in the
future anyway.
If the hostname was changed while NM wasn't running, and thus /etc/hosts
was out of sync with the new hostname, NM wouldn't make sure that
the new hostname was mapped in /etc/hosts. Make sure that happens
and add a bunch of testcases for /etc/hosts rewriting.
Link against libm (using the LT_LIB_M macro and the $LIBM variable) as
we are using pow() and otherwise fail to build with stricter linkers like
binutils-gold.
Automatic IPv6 configuration is handled by the kernel, but to
integrate it properly with NetworkManager, we need to watch what the
kernel does to see whether or not it was successful (so that we can
let the user know if there is no IPv6 router present, for example).
NMIP6Manager takes care of this.
The only thing that doesn't work yet is the system-settings service's
"auto eth" connections for ethernet devices that don't have an existing
connection. Might also have issues with unmanaged devices that can't
provide a MAC address until they are brought up, but we'll see.
0.7 requires dbus 1.1 or greater (for system bus activation), so make that
explicit, and remove compat code for D-Bus 0.6 and earlier. Consolidate
the various glib pkgconfig checks into one, since most anything will require
gthread, glib, and gobject anyway. Fixup the docs makefile to be more
automake-compatible and let 'make clean' actually work correctly when
docs are built.
