Aleksander,
As always, we're very motivated to shave a second or a few hundred
milliseconds off the modem startup time :)
I guess a simple solution is to let a plugin specify the max number of
ports N, such that the plugin manager will skip the minimum probing
time after seeing the completion of N port probes. A more generic
solution would be adding a hook in the plugin to decide whether or not
to end the probing process after each port probe finishes. How do you
think?
Thanks,
Ben
On Fri, Jun 28, 2013 at 12:13 AM, Aleksander Morgado
<aleksan...@lanedo.com> wrote:
>
>> The following code in MMPluginManager seems to always wait until the
>> minimum probing time is consumed.
>>
>> /* If we didn't use the minimum probing time, wait for it to finish */
>> else if (ctx->timeout_id > 0) {
>> mm_dbg ("(Plugin Manager) '%s' port probe finished, last one
>> in device, "
>> "but minimum probing time not consumed yet ('%lf'
>> seconds elapsed)",
>> g_udev_device_get_name (port_probe_ctx->port),
>> g_timer_elapsed (ctx->timer, NULL));
>>
>> For a modem with known port layout (assuming we have a way to specify
>> in the plugin), once all port probes finish, should MMPluginManager
>> proceed without waiting for the minimum probing time to expire? Is
>> there a potential downside? The obvious upside is cutting the modem
>> startup time.
>>
>
> This is just to let the kernel some time to expose all the ports, and
> should only be a couple of seconds max. If the first probe is exposed
> and right away probed, and there is no other port around when the
> probing finishes, the whole device probing is assumed finished. Newer
> ports appearing afterwards should still get grabbed by the already
> created modem, but these ports will not take part in the probing
> decisions. But of course, if we have a way to specify the expected port
> layout in the plugin itself (in very device-specific plugins like the
> novatel-lte or altair-lte), then there is no point in waiting the
> minimum probing time if we already got the expected layout, of course.
>
> --
> Aleksander
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
