On Thursday 31 October 2013 12:00:10 Dan Williams wrote:
> .... If you're on a server, and that server does not
> have any "SMS me when you're down" functionality, then you may not want
> ModemManager installed there.
+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).
> But we'd also like to hear about devices
> that MM probes-but-shouldn't-probe so we can black/greylist them as
> appropriate.
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@xxxxxxxxxxxx http://users.actcom.co.il/~oron
"Microsoft: We make virii work!"
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
