Hi all, My understanding is that the whole support for caching capabilities after port probing is done so that if a plugin requests a probe, the remaining plugins to check for support don't need to relaunch a new port probe. If this is not the case, please stop reading now :-)
Port probing and grabbing usually falls under one of these options: (1) Usually only one single plugin does the port probing, checks capabilities, and grabs the port. Sometimes there is even no probing needed, as Samsung "net" subsystem devices. (2) Some other times a plugin does the port probing (vendor ID matches) but then can't grab the port (capability checks fails), so ModemManager ends up trying to default to the Generic plugin, which will use the already cached capabilities to check for support. With the RS232 modem support (not yet merged in master) there is still a new option: (3) A plugin which supports RS232 modems does port probing (didn't do vendor ID check with the udev-reported one), and finds that the vendor ID from AT+CGMI is not the one it expects, so doesn't go on. Then, next plugins checking for support will use the cached capabilities/vendorID/productID. There seems to be 2 problems in this logic: ----- Most (all?) implementations of grab_port() in the plugins rely on the fact that the port probing task they get as input argument is exactly the one which did the port probing: there are calls to mm_plugin_base_supports_task_get_probed_capabilities() usually in grab_port() in order to know if a GSM or CDMA modem object is to be created. This is even the case for the generic plugin, which means that if some other plugin did the real port probing, once the Generic plugin wants to grab the port (cases 2 and 3 above), the call to mm_plugin_base_supports_task_get_probed_capabilities() will return 0 and the port won't be grabbed, spitting something like: do_grab_port(): plugin 'Generic' claimed to support tty/ttyUSB0 but couldn't: (-1) (unknown) I guess this behaviour is undesired, we shouldn't make grab_port() assume that the supports task that gets as input is really the supports task that did the real probing. Or, otherwise, we could try to simulate that a port probing was done by that supports task by copying the cached capabilities within the supports task results. Any other suggestion on how to avoid this issue? ----- Another related issue comes from the fact that even for port probing, different plugins may have special needs: * The Huawei plugin needs AT^CURC=0 and AT^GETPORTMODE before launching the probe, for example. * In general, ModemManager allows plugins to setup a custom_init_command in the supports task, with a custom callback to report capabilities found in the response. Now, if there is any previous plugin that launched a probe on that same port and cached some invalid result of capabilities, the plugin with special probing needs will rely on the cached result and not launch a new probe, which is not good. I guess that for these plugins with special needs, we shouldn't rely on the cached capabilities stored by a previous supports task of another plugin, and always launch a new probe. This issue anyway is probably a little less worrying due to the fact that port probing is currently always launched once the vendor ID has been done; so only case (2) above would be affected by this, and in this specific case the Generic plugin (the one consuming the previously cached capabilities) doesn't need any special port probing needs. Once RS232 support gets in master, this issue may then affect also the case (3) above for plugins supporting RS232 modems. ----- What do you guys think about these two issues? Now I wonder if it is really worth all this caching of capabilities, when almost always port probing and grabbing will fall under case (1) above: only one single plugin does the port probing, checks capabilities, and grabs the port. Cheers! -- Aleksander _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
