We chain up the Generic plugin created MMBroadbandModem objects within the
GDBusObjectManagerServer in MMManager, so that they get properly exported in
DBus.
The MMManager object creation may fail due to environment reasons (i.e. no
plugins found, or problems exporting DBus interfaces), so we can use the
initable interface to properly handle those situations.
The MMManager object now derives from the gdbus-codegen-generated
MmGdbusOrgFreedesktopModemManager1Skeleton object, and implements the handlers
for the SetLogging() and ScanDevices() DBus methods.
The main program is also modified to be based on GDBus.
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.
Make port roles more flexible. We have modems that do PPP
on interfaces other than the primary interface, and that
wasn't possible with the old code. So clean up all that
logic and move the port organization code into the core
so we can reduce code in the plugins.
In the new world order, the plugins say whether the port
is a QCDM port, an AT port, or ignored. If it's an AT
port the plugins get to tag it as primary, secondary, or
PPP, or any combination of the 3. This allows for modems
where PPP should really be done on the secondary port
(Huawei E220, Sierra devices) so that the primary port
stays open for command and status.
Modem subclasses no longer get asked to handle port grabbing
themselves. Instead, that's now done by the generic classes
(MMGenericCdma and MMGenericGsm) and the plugins are notified
when a port is grabbed so they can add unsolicited response
handlers for it. After all ports are grabbed by the generic
classes, they get "organized", which assigns various ports
to the roles of PRIMARY, SECONDARY, DATA, and QCDM based
on specific rules and hints that the plugin provided (which
are expressed as MMAtPortFlags). The plugins then have
a chance to perform fixups on the primary port if they choose.
The plugin code is responsible for determining the port
hints (ie MMAtPortFlags) at probe time, instead of having
a combination of the plugin and the modem class do the
job. This simplifies things greatly for the plugins at
the expense of more complicated logic in the core.
Lifted almost entirely from similar code in NetworkManager.
BUG=chromium-os:15197
TEST='dbus-send --print-reply --system --dest=org.freedesktop.ModemManager /org/freedesktop/ModemManager org.freedesktop.ModemManager.SetLogging string:DEBUG'
Also try valid log levels 'ERR', 'WARN', 'INFO', and an invalid log level, such as 'ABCDE'.
Change-Id: I2bddcd0319f4966dd293b119f68e7cc1697949b7
Reviewed-on: http://gerrit.chromium.org/gerrit/3134
Tested-by: Nathan J. Williams <njw@chromium.org>
Reviewed-by: Eric Shienbrood <ers@chromium.org>
Note that even if a plugin says it wants to be sorted last, the generic plugin
will always be the last one. Also, there is no order guaranteed between two
plugins that request to be sorted last.
Ignore devices that aren't completely configured by udev yet. If
ModemManager is started in parallel with udev, explicitly requesting
devices may return devices for which not all udev rules have yet been
applied (a bug in udev/gudev). Since we often need those rules to match
the device to a specific ModemManager driver, we need to ensure that all
rules have been processed before handling a device.
Do this by adding an item to the environment of each device that MM
might possibly be interested in, and ignoring devices that don't
have that. When the device is fully processed by udev, MM will get
an 'add' event and the device will have all rules applied.
Found by jklimes. If some plugin already supports this port, it's
pointless to let Generic figure out if it supports the port since
we're just going to hand it to the other plugin anyway.
Since MMModem is an interface and doesn't store stuff like the
modem's physdev internally (since it's an interface) these things
are handled via GObject properties. And since g_object_get()
returns allocated values, we need to free the returned value
from mm_modem_get_device() after we're done with it.
The master device of PCMCIA-provided ports is typically the
last device in the PCMCIA subsystem, because the PCMCIA
controller is usually a PCI device or some other subsystem.
The next plugin logic was wrong when a previous plugin had already
claimed support for the port and the Generic plugin was next. In
that case, the code failed to call the functions to actually grab
the port.
Otherwise info->cur_plugin is wrong (and therefore we left uncleared
supports tasks in MMPluginBase) when the port isn't supported by
the plugin, but it's parent modem device was supported by the plugin.
Like when all probing of the port fails but one of it's siblings has
already been claimed by a modem; in this case we just drop the port
(so that no other plugin could try to claim it, because only one
plugin is allowed to handle all a modem's ports) but we still need
to tell the parent modem's plugin to clean up the supports task.
A modem is now only exported to D-Bus when both of the following are true:
1) the modem is valid
2) all ports the modem provides have been handled by appropriate plugins
This ensures that all the modem's ports are completely ready before
any clients can do anything with it. In the case of CDMA modems with
QCDM ports, this allows the QCDM ports to be detected before exporting
the modem. Since the QCDM detection comes after AT probing, previously
this resulted in a CDMA modem getting exported to clients before we had
a QCDM port to query for registration status.
Even just walking sysfs for driver and parent devices takes
time for ports we know we'll never use, so take a short-cut
and save some startup time. This reduces the startup
overhead to some 15%.
rfcomm devices seem to be created as 'virtual' devices first, without
any parents, then moved to the right place in the device tree. So
handle moves too; if the modem was already found in the 'add' phase
it'll be ignored in the move phase.
It helps make the supports/grab callchain less crappy to look at
in gdb by ensuring that the supports chain unwinds before the grab
happens, and also ensures that we use the right subsys/name variables
rather than depending on ones the plugin provided to supports_callback,
that may go be freed by the plugin somewhere in grab_port().
