RFC: New device filter policies

[Aleksander Morgado]

Hey!

>
>> Following the discussion regarding Debian wanting to patch
>> ModemManager to avoid unnecessary probing of non-modem TTYs
>
>
> This patch was great for us. I went ahead and re-based it on top of 1.6.10
> and it has been running on the PLS8-X/E without issue. I used the white-list
> option & think this is a really huge nice to have. I'd suggest adding the
> nice comment message example you have for using the white-list to the linked
> documentation though - I actually read the documentation first :). Also the
> documentation has a few minor syntactical errors, like under the API doc
> '--policy' instead of '--filter-policy'. I can add the ones I found if you'd
> like.
>

Thanks for trying this out. I've added a couple of follow-up "fixup!"
commits to the branch with those fixes, they will get automatically
rebased when preparing the branch to merge in git master. I've also
updated the html doc in fd.o:
https://www.freedesktop.org/software/ModemManager/api/1.8.0/ref-overview-modem-filter.html
https://www.freedesktop.org/software/ModemManager/api/1.8.0/ch03s02.html

In your case (building systems with one specific modem), tagging the
device with a whitelist is obviously the quickest way to solve the
problem of MM not probing other stuff. But, I bet that if you had used
--filter-policy=strict would have also been ok (the PLS8 has TTYs+NET
which would be matched by the MM_FILTER_RULE_TTY_WITH_NET filter) for
your use case, and it really wouldn't have been slower!.

> With the white-list I had a feature idea I'd like to pitch. I thought it'd
> be great if there was NetworkManager applet integration to control the MM
> white-list, such that, a user might initiate a MM full probing (like click
> to scan for new hardware) which would then build a MM white-list to be used
> in the future. Maybe this would even tie into a saved bearer config(?) and
> after that you'd fall back to the fast/less intrusive white-list. The NM
> applet could allow re-scan's for future hardware additions/removal. In this
> way you'd solve the hot MM issue of preventing the full udev probing yet MM
> still wouldn't have to try and maintain the impossible task of a udev
> whitelist for every modem out there. I'd be glad to try this and jump into
> the NM stuff if there was interest, though I can't say I'd ever get it out
> in a timely fashion. Thoughts?
>

I see what you're suggesting here. In your suggested setup,
ModemManager would never probe anything by default, unless explicitly
requested by the user e.g. via NM applet or some other means, and then
that would result in some "automatic" whitelist if a device is found.

I personally try to avoid this kind of interactions, as a user should
really not need to do anything to get a modem detected, which is
partially why using a "stricter" policy would be better: we try to
avoid probing unknown TTYs but we definitely probe modems. If an
unknown TTY is really a modem, we should improve the policy to catch
it somehow, ideally without needing to whitelist vid:pids or so. In a
perfect world, the strict policy would be the only thing needed to
catch all modems, and so we wouldn't require a whitelist at all, but
the world isn't perfect and there are non-USB RS232 modems :).

Anyway, you could run ModemManager with --no-auto-scan always by
default, and then have a third party tool, like an updated NM applet,
control which ports are probed by MM using the ReportKernelEvent()
API. Not saying that should be done, it's just a way it could be done
:)

> Anyways, our CI has run the white-list feature many times and it's working
> reliably for us. Hope that helps.
>

Good!

-- 
Aleksander
https://aleksander.es