NMClient and NMDevice used a 'lazy' approach for getting stuff from D-Bus, i.e.
requesting data from NM when they are asked for. However, for some cases, like
removing devices it is not optimal. libnm-glib will never see a device that was
removed, but not added during NMClient's lifetime.
So let's get devices list in NMClient's constructor and device properties
in NMDevice constructor to have the data from the beginning.
G_VALUE_HOLDS will fail if the value variable is NULL, so we only
want to check that the GValue holds the right type if the value
is valid. NULL means "no object path" in demarshallers.
Since D-Bus doesn't allow NULL or zero-length object paths, NM
uses "/" as a placeholder here. Make sure the generic marshalling
code handles that so we don't have to do it in multiple places and
simplify handling of NULL objects somewhat.
Like the *_filter_connections() functions, but for just one connection,
and now the *_filter_connections() functions call these new ones so
it's really just moving code around and not anything new.
These new functions more closely match the usage I've seen from
gnome-shell's network.js and elsewhere.
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.
Add the necessary annotations (the mininum required, that is those
on return values. NULL parameters or container types may require
more), and the Autotools stuff to get a NetworkManager GIR for
libnm-util and a NMClient for libnm-glib.
Heavily modify Inaky's Intel WiMAX SDK glue (originally from connman)
to be more generic and more thread-safe, and suitable for use with
NetworkManager instead of rolling our own client code. Rewrite the
NMDeviceWimax code to mostly work.
Still to be done: actual connection logic, DHCP handling, spawning
wimaxd if it's not started yet
Track missing firmware and ensure the device can't be used when firmware
is missing. Add a property for missing firmware so that clients can do
something intelligent with this information.
* include/NetworkManager.h
- Add the DHCP4Config D-Bus interface
* libnm-glib/Makefile.am
libnm-glib/nm-dhcp4-config.c
libnm-glib/nm-dhcp4-config.h
- Handle DHCP4 config objects exported by NM over D-Bus
* libnm-glib/nm-device.c
libnm-glib/nm-device.h
- Add a 'dhcp4-config' property
* libnm-glib/libnm-glib-test.c
- Print out DHCP4 config for devices
- Fix some crashes when no connections are active
* src/nm-device-interface.c
src/nm-device.c
src/nm-dhcp4-config.c
src/nm-dhcp4-config.h
- Treat dhcp4-config object as an object path at the D-Bus interface so
that when it doesn't exist we can proxy it as "/" which dbus-glib
doesn't let us do when the property type is G_TYPE_OBJECT
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3905 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
* libnm-glib/nm-device.c
- (proxy_get_string): util function for querying a HAL property
- (get_ancestor_device): split out from get_product_and_vendor()
- (get_product_and_vendor): simplify; get more accurate pid & vid info
from PCI devices by querying subsys properties
- (nm_device_update_description): simplify
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3883 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Modify the NMDevice::state-changed signal to include the previous state
and reason. Enables the applet to provide more information why device
activation failed.
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3819 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
* libnm-glib/nm-ip4-config.c
libnm-glib/nm-active-connection.c
libnm-glib/nm-access-point.c
- Use nm_object_queue_notify() instead of g_object_notify()
* libnm-glib/nm-device.c
- (demarshal_ip4_config): distinguish between successful but missing
ip4-config request, and unsuccessful and missing ip4-config request
- (nm_device_get_ip4_config): don't try to demarshal a NULL ip4-config
path
- Use nm_object_queue_notify() instead of g_object_notify()
* libnm-glib/nm-device-802-11-wireless.c
- (demarshal_active_ap): distinguish between successfull but missing
active-ap request, and unsuccessful and missing active-ap request
- (dispose, clean_up_aps): consolidate AP list and active AP clearing
code
- (nm_device_802_11_wireless_set_wireless_enabled): add a private hook
for the NMClient to notify the device that wireless is disabled,
and therefore to clear the AP list and active AP
- Use nm_object_queue_notify() instead of g_object_notify()
* libnm-glib/nm-client.c
- (poke_wireless_devices_with_rf_status): new function
- (update_wireless_status): notify wireless devices of the rfkill status
so they can clean up if needed
- Use nm_object_queue_notify() instead of g_object_notify()
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3502 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
