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. > This is because I am integrating a modem to a device. And I have developed my > own plugin for the modem with some optimization. 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... > 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. > 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. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel