mbim-proxy: open retries

[Aleksander Morgado]

Hey Greg,

Next thing I've found during my tests, is that when using the proxy
the open retries logic that we have doesn't make proper sense any
more.

One of the issues I found is that we assume the MbimDevice is open as
soon as we have a iochannel internally. That's wrong, because the
iochannel is created during the MBIM Open procedure, but it is kept
open both while we're still trying to open and also if we fail the
open. The tests I've done are with non-MBIM /dev/cdc-wdm ports; in
this case, we never get an MBIM Open response, but still clients using
the proxy will get notified that the device is open (so, e.g.
ModemManager could end up thinking the /dev/cdc-wdm port is really an
MBIM device while it's not). That's something we should handle
somehow.

The other issue is regarding open retries. We added a set of open
retries in case some devices needed time to settle before correctly
replying to the Open request. With the proxy running in, the proxy
itself ends up handling the retries; but the clients who requested
that open will not (as soon as the iochannel is built, the MbimDevice
is assumed open, as in the previous paragraph). So that takes us to
what to do with the retries. Should clients handle those themselves
(i.e. the proxy would just be proxying the retry Open requests)? Or
should the proxy itself somehow take care of the full Open logic with
the device, including the retries logic? In this latter case, we could
delay the Open requests from the client until we get one of the Open
retries replied by the device. We would need to queue these requests
one after the other, and reply them all together. Clients will have
their own timeouts anyway for each reply, so that shouldn't be an
issue.

If the proxy ends up taking care of the actual open status of the
device, we could also monitor for "not open" errors reported by the
device (e.g. when coming back from suspend/resume cycle) and
automatically re-open the device internally in the proxy.

I believe that, since we're not going to explicitly close MBIM devices
when using the proxy, the proxy itself should handle opening them as
soon as it gets notified about the port to use. So, we could directly
open (try to open) the device as soon as we get the internal proxy
configuration message; then when Open requests come from clients, just
delay them until the internal Open is finished.

If we do that that way there should also not be any problem with
multiple processes requesting MBIM Open, which is also another issue
going on right now...

What do you think?

P.S.: thinking in making a new stable libmbim release, and just merge
the proxy stuff afterwards in git master to keep experimenting.

-- 
Aleksander
https://aleksander.es