Bug #4916
openUSB unplug / replug renders e1d unusable
30%
Description
- e1d keeps running
- e1d does not re-open the device when it comes back
- fail fast - simply exit when the device is lost, assume systemd or some other management instance will keep respawning us until the device is back
- but what about client programs like osmo-bsc / osmo-mgw ?
- implement re-opening of a single icE1usb device, knowing our blocking control transfers would corrupt any other ongoing communication
- is it worth the effort, assuming this is only an interim solution
- go for a full-blown hot-plug capable architecture lined out in #4915
- will probably take significant effort
I think right now we mostly have to worry about situations with a single icE1usb, so I'm tempted to go for the fail-fast approach, assuming osmo-bsc/osmo-mgw recover in some way.
Related issues
Updated by laforge about 2 years ago
- Status changed from New to Stalled
- % Done changed from 0 to 30
I did some work on this in the laforge/hotplug branch - which uncovered quite a bit of libosmousb bugs, e.g. https://gerrit.osmocom.org/c/libosmocore/+/27038
Updated by laforge about 2 years ago
For the record: The main problem with the code in that branch is that we have the following flow of events:
- we register call-backs for hotplug insert/remove
- libusb calls the insert call-back function once a device is detected
- once a device is found, we want to obtain the iSerial string to match against config
the existing code does that using a synchronous/blocking call. That's bad as it causes the process to hang/stall for all other devices osmo-e1d might already be serving. But even worse than that: libusb doesn't permit such calls from the "call-back context".
So we have to introduce some kind of stae machine which then sends a non-blocking/asynchronous read of iSerial from the hotplug notifiation context. Only once that read completes, we can proceed with enabling the interfaces of the device.
Updated by laforge about 1 year ago
- Related to Feature #5983: Exit if osmo-e1d goes down or is restarted added
Updated by laforge 5 months ago
laforge wrote in #note-2:
For the record: The main problem with the code in that branch is that we have the following flow of events:
- we register call-backs for hotplug insert/remove
- libusb calls the insert call-back function once a device is detected
- once a device is found, we want to obtain the iSerial string to match against config
the existing code does that using a synchronous/blocking call. That's bad as it causes the process to hang/stall for all other devices osmo-e1d might already be serving. But even worse than that: libusb doesn't permit such calls from the "call-back context".
So we have to introduce some kind of stae machine which then sends a non-blocking/asynchronous read of iSerial from the hotplug notifiation context. Only once that read completes, we can proceed with enabling the interfaces of the device.
An alternative would be to have a separate "hotplug thread" which we register with libusb to receive the hotplug call-back. It can then do as many blocking calls as it needs to do (there are actually more than just the iSerial string) and once it's done, pass the device over to the main thread to do its usual non-blocking processing.
