<div dir="ltr">Hi Aleksander,<div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 18, 2014 at 5:05 AM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hey Greg,<br>
<div><div class="h5"><br>
On Sat, Jan 18, 2014 at 12:11 AM, Greg Suarez <<a href="mailto:gpsuarez2512@gmail.com">gpsuarez2512@gmail.com</a>> wrote:<br>
> I was wondering if anyone as thought about or started working on adding an<br>
> interface to allow OEM apps to make use of proprietary MBIM extensions<br>
> through ModemManager?<br>
><br>
> I was thinking along of the lines of allowing the app to send binary blobs<br>
> along with the UUID and CID and ModemManager will pass along the message to<br>
> the device and look for responses with the matching UUID and CID to pass<br>
> along the binary response back to the app.<br>
> Also ModemManager would need to provide a mechanism for the app to subscribe<br>
> to notifications from a matching UUID.<br>
><br>
> Any thoughts or a better way?<br>
<br>
</div></div>I think that it makes more sense to setup something like the<br>
'qmi-proxy' that we have in libqmi; i.e. a 'mbim-proxy'. This new<br>
proxy would be the one opening the actual cdc-wdm device, and it would<br>
then allow different processes to connect to the proxy and share the<br>
actual connection with the device. This would allow both ModemManager<br>
and other processes to talk MBIM at the same time. The mbim-proxy<br>
would be a bit different than the qmi-proxy, as there is no<br>
'client-id' logic within the MBIM protocol, so that would need to be<br>
managed by the proxy itself (i.e. keep a table of ongoing transactions<br>
in each remote client). Also, notifications should be handled<br>
differently; in the qmi-proxy case we could send non-broadcast<br>
notifications only to the client expecting them, but in the case of<br>
the mbim-proxy, we would need some other way to handle that. Maybe<br>
allowing clients to 'register' to specific notifications and keeping<br>
that logic within the proxy...<br><span class=""></span></blockquote><div> </div><div>Thanks for the response.  That sounds like the perfect solution.  I'll look at the qmi-proxy code and come back to you with questions and ideas.</div>
<div><br></div><div>Greg </div></div><br></div></div>