Assign specific plugin for my modem

Aleksander Morgado aleksander at aleksander.es
Wed May 20 11:41:53 UTC 2020


Hey,

>> > I'm now developing my application with ModemManager.
>> > I want to add a feature that can directly assign which plugin to use for my modem. Instead of using the filter to match appropriate plugin.
>> >
>>
>> I'm not totally sure we'd like to support this, truth be told. The
>> different available plugins exist to handle different available
>> devices. There should be no device that is "better" managed by a
>> different plugin than the one ModemManager thinks is best; at the end
>> ModemManager knows what each plugin can do. A different thing would be
>> the "generic" plugin that is used as fallback if none other applies
>> better; in this case, the solution is to implement a new plugin for
>> the new device.
>
>
> Sorry that I didn't say it clearly.
> ModemManager is a general tool. One plugin can support many kinds of modems.

Yes, and if per-device specific settings are required, we would need
to either upgrade the plugin to handle those, or even setup a full new
plugin just for that device type.

> I'm afraid that my optimization for one single modem may affects other modem supported by the plugin.
> So I separated it in my current development process.
>

That's a normal thing to consider when developing ModemManager. But
depending on what change it is, we may want to have it for all devices
of the same plugin.

>> > This is because I am integrating a modem to a device. And I have developed my own plugin for the modem with some optimization.
>>

Then you should either suggest the changes upstream, so that they're
included in the official MM releases, or just keep your changes as
patches that you apply to your build tree.

>> Did you take an already existing plugin and update it? If so, you
>> should keep your own build of ModemManager and just patch the existing
>> plugin.
>> What does your own plugin do? Is it for a completely new device?
>> Please remember that there is no real guarantee that a plugin
>> developed out-of-tree will be compatible between different MM
>> versions...
>
>
> Can I ask that if I finally have some patches for a plugin.

Yes please, send the patches to us for review and inclusion!

> How can I push them to ModemManager?
> Should I send the patch to this mailing-list or a merge request?
>

A new merge request in gitlab would be best.

>>
>> > In this situation, I already know which plugin to use for my modem. Currently I use a simple way to achieve. I create a udev tag "ID_MM_SUGGESTED_PLUGIN", it's usage is the same as "ID_MM_PHYSDEV_UID". Once the device is detected with this tag, I'll set it as the suggested plugin.
>> > I posted my branch here: https://gitlab.freedesktop.org/kenchou0731/ModemManager/-/commit/117c9dcf655007ed57a4a248856df1f4b47bd814
>> >
>>
>> We shouldn't let users select the plugin that way I'm afraid. I don't
>> think that's a sane approach for a general use. If you're building
>> your own system with always the same kind of modem, why don't you just
>> install that single plugin only? I've done that kind of setup for
>> several customers and it have worked quite well. Moreover, in MM git
>> master and the new 1.14 release soon, you will be able to select at
>> configure time which plugins you want to build and install.
>
>
> Yes, to just install the single plugin is a good solution.
> I'm glad to hear that  new 1.14 release will have the option to configure which plugins you want to build and install.
> It's helpful for me.
>

Nice!

>>
>> > Furthermore, I want to do some enhancement for this.
>> > My application will sometimes need to reset modem (for changing USB configs or changing carrier profile). ModemManager will do the filter for finding plugin for every ports of the modem. This procedure took about 1 second with the debug log enabled. And it may took longer if ModemManager supports more and more plugins in the future.
>> > I think this procedure can be skipped if I'm sure that which plugin to use. And I can reduce the downtime of modem being reset.
>>
>> I really don't think this is an issue, at least if the plugins are
>> correctly setup. The plugin selection has several steps; for plugins
>> based on USB like yours, the per-VID/PID filter rule is a simple int
>> comparison that is very very quick to decide whether a plugin is
>> expected for a device or not. Even if we have 100 plugins, the per-VID
>> filter that applies to most of them would make the process very very
>> quick. I wouldn't attempt to optimize this very much because it truly
>> should be very very quick. For other filter decisions it may take some
>> more time, e.g. if it needs to do AT vendor probing for RS232 modems,
>> but that is totally understandable because there is no better option.
>
>
> Understand. I don't think this should be an issue for ModemManager.
> I'm just thinking that how can I reduce the downtime for modem during reset.
> And I'll try it with only install the single plugin. Thank you!
>

If device probing is slow, you may want to add "port type hints" via
udev tags, as we do for lots of other devices.

-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list