[PATCH 3/5] core: allow disabling auto-scan and notifying ports one by one via API

Aleksander Morgado aleksander at aleksander.es
Fri Sep 30 07:25:52 UTC 2016


On Fri, Sep 30, 2016 at 5:56 AM, Dan Williams <dcbw at redhat.com> wrote:
>> 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).
>
> Generally LGTM.  One thing I'm not clear on though.  For the
> MMKernelUdevDevice, what does it need to keep the Properties object
> around?  It seems like there's a lot of new complexity to first check
> self->priv->device and if that doesn't exist then use self->priv-
>>properties.
>
> Shouldn't there always be a self->priv->device since it gets set during
> object init?  Initialization is synchronous anyway...
>
> I guess the question is, when will there not be a self->priv->device?

There won't be a self->priv->device on "remove" events notified via
ReportKernelEvent(). In this specific case, we create the
MMKernelDeviceUdev with mm_kernel_device_udev_new_from_properties()
but we don't query a GUdevClient for subsystem+name because the port
may already be gone, and we still need to MMKernelDeviceUdev around to
process the action.

-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list