ModemManager and generic USB hardware (was: Fatal flaw in the udev paradigm?)

On Thursday 31 October 2013 12:00:10 Dan Williams wrote: +1 But also in other cases, like the following: * Software/hardware developer use a Linux laptop * They remove ModemManager so it won't mess with their electronic hardware testing. * Later on, they are on the road and need something urgently. * No problem, we have GSM modem, but... it's not working... * No problem, we'll re-install ModemManager, but... we need a chicken for this egg (or maybe vice versa ;-) All of this just begs for a global disable flag for ModemManager: * This should probably go into NetworkManager. * It should be a boolean runtime flag, e.g: some dbus property. * This way it could be exposed in UI (enable/disable modems). While this will solve many problematic cases, it would still leave a lot of unresolved cases: * Either permanently (because of broken hardware) * Or temporarily (until packages with updated graylist are installed). [yes, the admin may create something temporary in /etc/udev/rules.d but I'm talking from a *user* pov] It looks like ModemManager should be able to pass some decision to the end user. Here is one possible model for doing this: * All *potential* modem devices (serial ports, known USB id's, etc.) that are reported to ModemManager build a list of "Possible modems". * However, ModemManager scan all this list *only if* a "scan_all_devices" property is "true" -- in this case, it behaves like today. * Even when this property is "false", the user would be able to call a new "ScanDevice(dev)" method to scan *a specific* device (from the "possible modems" list). Combining the two changes with the suggested global disable flag, would allow a UI (e.g: nm-applet) to provide an interface which is both easy to grasp and highly flexible (IMHO): * With "modems" disabled -- everything is silent. * With "modems" enabled -- the user can see a list of devices: - The UI may optionally augment this list with some sysfs properties if they exist (e.g: idProduct for USB devices, or the strings from the USB hardware database, etc.) -- this extra info is public anyway and doesn't require any MM involvement, it's just a UI thingy. - If "scan_all_devices" is true, the UI may augment the list display during the scan by MM. E.g: gray out devices that haven't responded yet, show some progress for currently scanned device, display SIM information when MM read it, etc.) - OTOH, if "scan_all_devices" is false, the user may click a specific device from this list to start "ScanDevice(dev)" on it. * Optionally, the UI may implement further selection rules. For example: - Allow the user to "blacklist" specific devices in the UI. - This "blacklist" would be a UI list (i.e: client side). - The UI would simply "ScanDevice(dev)" all other devices, so MM wouldn't know/care about the extra granularity that was added by the UI. Last, unrelated, suggested MM udev tweak: * A lot of USB modems have several USB interfaces which translates to several /dev/ttyUSB* etc. * Some of the drivers (e.g: ZTE) provide a way for udev rules to hint them about the preferred "MODEM" interface, e.g: ... ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1" * Since there are so many "no-name/broken" USB modems out there, it would be nice if this provision could be re-factored so it would apply to any USB modem plugin (including the "generic" one): ... ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_PORT_TYPE_MODEM}="1" Now I wait to see: A. If these ideas are just stupid and I don't understand anything about MM. B. Or they are OK, but MM people cannot be expected to implement any random nice idea suggested by "someone on the Internet"... If it's B. -- please let me know and I'll try to see if I can prototype something that may even function on some lucky days ;-) Thanks, -- Oron Peled Voice: +972-4-8228492 oron(a)actcom.co.il http://users.actcom.co.il/~oron "Microsoft: We make virii work!"