g_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
So that we don't leak the port names allocated within each
MMModemPortInfo.
==261== 672 bytes in 84 blocks are definitely lost in loss record 7,314 of 7,383
==261== at 0x402C51E: malloc (vg_replace_malloc.c:299)
==261== by 0x4484878: g_malloc (gmem.c:94)
==261== by 0x449D51D: g_strdup (gstrfuncs.c:363)
==261== by 0x44B5B73: g_variant_dup_string (gvariant.c:1529)
==261== by 0x44B945E: g_variant_valist_get_nnp (gvariant.c:4775)
==261== by 0x44B945E: g_variant_valist_get_leaf (gvariant.c:4945)
==261== by 0x44B945E: g_variant_valist_get (gvariant.c:5126)
==261== by 0x44B922C: g_variant_valist_get (gvariant.c:5161)
==261== by 0x44B9FC9: g_variant_get_va (gvariant.c:5388)
==261== by 0x44BA3C5: g_variant_get_child (gvariant.c:5486)
==261== by 0x6613FA8: mm_common_ports_variant_to_garray (mm-common-helpers.c:238)
==261== by 0x6601AB9: ensure_internal_ports (mm-modem.c:766)
==261== by 0x6603E42: mm_modem_peek_ports (mm-modem.c:825)
==261== by 0x65CD94D: owns_port (nm-modem-broadband.c:196)
Reported-by: Piotr Figiel <p.figiel@camlintechnologies.com>
==261== 482 bytes in 12 blocks are definitely lost in loss record 7,290 of 7,383
==261== at 0x402C51E: malloc (vg_replace_malloc.c:299)
==261== by 0x4484878: g_malloc (gmem.c:94)
==261== by 0x449D51D: g_strdup (gstrfuncs.c:363)
==261== by 0x44B5B73: g_variant_dup_string (gvariant.c:1529)
==261== by 0x44B945E: g_variant_valist_get_nnp (gvariant.c:4775)
==261== by 0x44B945E: g_variant_valist_get_leaf (gvariant.c:4945)
==261== by 0x44B945E: g_variant_valist_get (gvariant.c:5126)
==261== by 0x44B922C: g_variant_valist_get (gvariant.c:5161)
==261== by 0x44B9FC9: g_variant_get_va (gvariant.c:5388)
==261== by 0x44BA1DB: g_variant_get (gvariant.c:5335)
==261== by 0x664E2EF: mm_gdbus_modem_simple_call_connect_finish (mm-gdbus-modem.c:22451)
==261== by 0x6608A08: simple_connect_ready (mm-modem-simple.c:154)
==261== by 0x429136F: g_task_return_now (gtask.c:1107)
==261== by 0x4291A69: g_task_return (gtask.c:1165)
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
Instead of relying on the udev daemon and GUDev to manage the devices reported
by the kernel, we can now run ModemManager relying solely on the kernel events
reported via the new ReportKernelEvent() API. Therefore, the '--no-auto-scan'
option is implicit for the ModemManager daemon when udev is disabled in the
build.
Additionally, a new custom implementation of the kernel device object is
provided, which uses sysfs to load the properties and attributes required in
each kernel device, instead of using a GUdevDevice.
The udev rule files are kept in place, and a simple custom parser is provided
which preloads all rules in memory once and then applies them to the different
kernel objects reported via ReportKernelEvent(), e.g. to set port type hints.
A simple unit test setup is prepared to validate the udev rules during the
`check' Makefile target.
This commit enables a new core ModemManager daemon option, so that automatic
detection of available modems is totally disabled: '--no-auto-scan'. Note that
this option also replaces the previously used '--test-no-auto-scan' option,
which was only used during tests.
Along with the new ModemManager option, a new ReportKernelEvent() method in
the API is defined, which allows notifying the daemon of which interfaces it
should be accessing, as well as the main details of each interface. The only
mandatory parameters in the new method are 'action' (add/remove), 'name' (the
name of the interface) and 'subsystem' (the subsystem of the interface).
The mmcli tool has support for using the new api method via several new options:
* The '--report-kernel-event' option allows specifying device ports one by
one, and is a direct mapping of the ReportKernelEvent() method:
$ sudo mmcli --report-kernel-event="action=add,name=wwan0,subsystem=net"
$ sudo mmcli --report-kernel-event="action=add,name=cdc-wdm0,subsystem=usbmisc"
* The '--report-kernel-event-auto-scan' option uses udev monitoring to notify
events automatically to the daemon. This allows to operate in a way
equivalent to the default daemon operation (with implicit auto-scan).
Worth noting that the ReportKernelEvent() method is only usable when
'--no-auto-scan' is explicitly used in the daemon. An error will be reported if
the method is tried while standard udev monitoring is enabled (implicit if
auto scan isn't explicitly disabled in the daemon).
If mmcli is going to be used only to report 'real time' events, an optional
'--initial-kernel-events=[PATH]' may be given in the ModemManager call to
automatically process a set of port kernel events one by one on boot. The file
may e.g. contain:
action=add,name=wwan0,subsystem=net
action=add,name=cdc-wdm0,subsystem=usbmisc
We may want to use the mm_get_()_from_match_info() calls to read optional items,
so that the method returns FALSE if the item index doesn't apply. So, avoid the
implicit warning issued by g_return_val_if_fail().
The "0" case wasn't being handled properly:
$ sudo mmcli -m 0 --create-bearer="apn=,allow-roaming=0"
Error parsing properties string: 'Cannot get boolean from string '0''
mm-modem-oma.c:400:51: error: implicit conversion from enumeration type 'MMOmaSessionType' to different enumeration type 'MMOmaFeature'
[-Werror,-Wenum-conversion]
g_return_val_if_fail (MM_IS_MODEM_OMA (self), MM_OMA_SESSION_TYPE_UNKNOWN);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmessages.h:382:11: note: expanded from macro 'g_return_val_if_fail'
return (val); \
~~~~~~ ^~~
This should be MMOmaFeature, not MMOmaSessionType. The end result is the same,
as both are 0.
html/MMCallProperties.html:141: warning: no link for: 'mm-modem-voice-create' -> (<code class="function">mm_modem_voice_create()</code>).
html/MMCallProperties.html:141: warning: no link for: 'mm-modem-voice-create-sync' -> (<code class="function">mm_modem_voice_create_sync()</code>).
html/MMModemVoice.html:379: warning: no link for: 'mm-modem-voice-delete-finish' -> (<code class="function">mm_modem_voice_delete_finish()</code>).
html/MMModemVoice.html:380: warning: no link for: 'mm-modem-voice-delete-sync' -> (<code class="function">mm_modem_voice_delete_sync()</code>).
The rule with multiple targets means that for each of the target the command
specified is run; not that a single run of the command generates all the targets
specified.
So, generate the .c file with the command, and make the .h and the .xml files
a side-effect of the .c generation.
The default setup uses a refresh time of 30s, which means that even if the GPS
location updates are received at a higher frequency, the DBus interface will
still expose at most one update every 30s.
This patch includes a new "SetGpsRefreshTime()" method in the Location
interface, which takes a single 'u' parameter, specifying the refresh rate to
use, in seconds. This method also allows 0 being passed, which will make the
implementation to publish the GPS location updates are soon as ModemManager
detects them.
Along with the new method, a "GpsRefreshTime" read-only property is exposed
to specify the refresh time in effect.
The new method and property will only be applicable if the device has GPS
capabilities.
https://bugs.freedesktop.org/show_bug.cgi?id=89924
Build all targets, except for CLI tools (mmcli, uml290), with special
flags needed for collecting code coverage information when the build has
been configured with --enable-code-coverage.
Three new targets are available in the top build directory:
- `check-code-coverage' runs the test suite and generates a code
coverage report,
- `code-coverage-capture' generates a code coverage report from already
collected data, which can come in handy when one wants to see code
paths touched by a particular test,
- `code-coverage-clean' removes the collected coverage data and the
generated reports.
In mm_modem_messaging_get_supported_storages(), initialize array to avoid a
potential crash with an uninitialized value, and a build failure due to
mm-modem-messaging.c:168:24: error: 'array' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
*n_storages = array->len;
https://bugzilla.gnome.org/show_bug.cgi?id=729267
This patch adds a 'mtu' value to the Ip4Config and Ip6Config property of
a Bearer object, which indicates the value of the maximum transmission
unit for the established connection when such information is available
(e.g. via QMI_WDS_GET_RUNTIME_SETTINGS on a QMI modem or
MBIM_CID_IP_CONFIGURATION on a MBIM modem).
ensure_internal_ports() didn't deep-copy the ports array, which
meant that anything calling mm_modem_port_info_array_free() was
freeing the internal memory owned by MMModem if it retrieved
the array with mm_modem_get_ports().
https://bugzilla.gnome.org/show_bug.cgi?id=724900
