Re: ModemManager: issues with port probing and cached capabilities

> Most (all?) implementations of grab_port() in the plugins rely on the
> fact that the port probing task they get as input argument is exactly
> the one which did the port probing: there are calls to
> mm_plugin_base_supports_task_get_probed_capabilities() usually in
> grab_port() in order to know if a GSM or CDMA modem object is to be
> created. This is even the case for the generic plugin, which means that
> if some other plugin did the real port probing, once the Generic plugin
> wants to grab the port (cases 2 and 3 above), the call to
> mm_plugin_base_supports_task_get_probed_capabilities() will return 0 and
> the port won't be grabbed, spitting something like:
>    do_grab_port(): plugin 'Generic' claimed to support tty/ttyUSB0 but
> couldn't: (-1) (unknown)
> I guess this behaviour is undesired, we shouldn't make grab_port()
> assume that the supports task that gets as input is really the supports
> task that did the real probing. Or, otherwise, we could try to simulate
> that a port probing was done by that supports task by copying the cached
> capabilities within the supports task results. Any other suggestion on
> how to avoid this issue?

I already implemented a fix for this in the 'plugin-cinterion' branch in
my repo:

The fix involves changing all plugins so that, in supports_port(), they
don't call mm_plugin_base_get_cached_port_capabilities (). Instead, they
call a new mm_plugin_base_supports_task_propagate_cached(). This new
method will check if already cached probed results are available, and if
so, it will propagate the cached results to the supports task itself, so
that if supports_task_get_probed_capabilities() is called afterwards, a
copy of the cached ones is returned.

With this fix, a plugin trying to grab a given port does not depend on
having done the probe itself, as the supports task will always contain
either a copy of the previously cached results, or the results of a
newly launched probe.

Note that the commit above alone is not merge-able in master, as it's
based on the not-yet-merged cinterion-plugin branch.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]