Running ModemManager without udev

[Aleksander Morgado]

Hey everyone,

This series of patches introduces support to avoid requiring udev in ModemManager. The main use case is being able to use ModemManager under OpenWRT: assuming it is built with DBus and GLib/GIO, a simple set of hotplug scripts may be used in this case to report the kernel events to ModemManager.

The main key points implemented are:

1) The usage of the GUdevDevice is hidden behind a new MMKernelDevice object, for which we provide a GUdev-based backend. When udev isn't used, we use instead a sysfs-based generic backend.

2) Instead of relying on udev for getting notified of available kernel devices, we now provide a new "ReportKernelEvent" method in the Manager DBus interface, which may be used to report 'add' or 'remove' actions. Note that this method to report kernel events may also be used if built with udev support and the ModemManager daemon is run explicitly with --no-auto-scan.

E.g. when we want to report that wwan0 is available in the system, mmcli may be used to do so as follows:

$ sudo mmcli --report-kernel-event=" \
                action=add, \
                name=wwan0, \
                subsystem=net

I've used this feature extensively already when testing modems, e.g. in a multi-TTY device, adding one single TTY at a time to check how ModemManager processes the different single-TTY modems.

This feature may also be used to externally decide when ModemManager is able to see and process a given set of ports, instead of assuming it will use the ports as soon as they appear.

3) A new --initial-kernel-events="PATH" is available in ModemManager to process a set of initial kernel events during daemon startup. This method may be used to process events that happened before ModemManager started, or even to fix which are the ports that ModemManager may use and which may not.

4) We relied on udev tags to identify e.g. port type hints for different plugins, or to know whether a given VID:PID was blacklisted or greylisted. We still do this, but when not building udev support, now we parse the list of ModemManager udev rules ourselves in the generic sysfs-based MMKernelDevice.

5) We used to use the GUdevDevice only during device probing, and when creating the modem objects we just passed the port type/subsystem/names. Instead of doing this, we now pass along the new MMKernelDevice, and re-use it as much as needed in the different MMPort APIs. This allows, for example, to avoid requiring a new GUDevClient in the Huawei plugin, as we can already query the udev properties set in the ports directly from the MMKernelDevice.

Comments welcome!

 [PATCH 01/10] device: identify physical devices with a generic 'uid'
 [PATCH 02/10] kernel-device: new generic kernel device object, with a
 [PATCH 03/10] build: make gudev support optional
 [PATCH 04/10] api: new ReportKernelEvent() api method to report
 [PATCH 05/10] base-manager: if udev supported, use MMKernelDeviceUdev
 [PATCH 06/10] main: new '--no-auto-scan' to skip udev monitoring even
 [PATCH 07/10] mmcli: new '--report-kernel-event-udev' to report
 [PATCH 08/10] base-manager: process initial kernel events from an
 [PATCH 09/10] base-modem: mm_base_modem_grab_port() receives a
 [PATCH 10/10] huawei: no need to explicitly udev query, as we already