The new mm_plugin_manager_is_finding_port_support() allows to check whether the
Plugin Manager is looking for support in a specific port.
The new mm_plugin_manager_is_checking_device_support() allows to check whether
the Plugin Manager is looking for support in any port of a given device.
As soon as the first support check of a port in a given device finishes with a
valid best plugin and level > 0, propagate the result to other support tasks
corresponding to ports in the same physical device.
Previously, this propagation of support check results was only done once the
port was grabbed by a plugin, not just when the plugin reported that it
supported it. This change in behaviour isn't probably a big deal, as there
should not be any case where a plugin says it supports a port and then cannot
grab it.
We will keep a reference to each of the support checks currently in progress,
grouped by physical device path. The stored SupportsInfo structs as well as
the support check operations, are guaranteed to be kept valid as long as the
Plugin Manager exists. Or in other words, the Plugin Manager cannot be disposed
if there is still an ongoing supports check operation.
The new `mm_plugin_manager_find_port_support()' method requests the Plugin
Manager to iterate over the list of plugins internally handled, launching
supports task for the given port in each of them.
The method is fully asynchronous, and the result can be retrieved with
`mm_plugin_manager_find_port_support_finish()' once the operation is ready.
We now have 'supports_port' (async method) and 'supports_port_finish' (to get
the result of the async method), so it makes sense to rename the method to
'supports_port_cancel'.
Before this change, supports check was either synchronous (e.g. in some
UNSUPPORTED cases) or asynchronous (when IN_PROGRESS was returned).
With this fix, the supports check requested to the plugin will always be
completed asynchronously; either directly in an idle before launching any real
probing operation, or once the probing operation is finished.
Therefore, it is not expected to get a IN_PROGRESS reply in
mm_plugin_supports_port_finish(), only UNSUPPORTED|SUPPORTED|DEFERRED.
While porting to GDBus, use opaque pointers. This allows us to include either a
DBusGMethodInvocation or a GDBusMethodInvocation in the 'context' pointer.
Once fully ported to GDBus, we can safely change it back to make the context be
a GDBusMethodInvocation.
Also removed the MMSerialError implementation from `src/mm-errors.[h|c]', as it
is now included in the new `include/ModemManager-errors.h' header file. All the
other enums and errors without clashing names will be ported afterwards to the
new base code.
The code to handle the Enums and Flags type information is automatically built
with `glib-mkenums' and the new templates kept under `build-aux'.
Note: We currently skip the type information of `MMModemBand'. GFlagsValue
can hold only 32-bit types, and we're working with a 64-bit flag here.
See: https://bugzilla.gnome.org/show_bug.cgi?id=663054
This library will not (probably) be installable, but will share the GDBus
and new Enum/Flag/Error type support between the core daemon and the new
libmm-glib library.
Keep the Bearer interface out of the 'Modem' subtree in the interface hierarchy,
as it will be specific for Bearer objects, not implemented by Modem objects.
Keep the SMS interface out of the 'Modem' subtree in the interface hierarchy,
as it will be specific for SMS objects, not implemented by Modem objects.
The Scan() method returns an array of dictionaries, where each dictionary is
defined by a string key plus a variant data (not a string data). This is to
handle the "status" and "access-tech" entries, which are given as unsigned
integers.
