[PATCH] libmbim: Add mbim-proxy support
gpsuarez2512 at gmail.com
Sun May 25 22:42:02 PDT 2014
On Sat, May 24, 2014 at 10:51 PM, Aleksander Morgado <
aleksander at aleksander.es> wrote:
> I don't think there is a point in adding the limitation just due to 1
> service behaving that way.
I have a feeling that if one OEM does it there will be others who do it.
Even ignoring this one service we're going to run into this, on a smaller
once OEMs start implementing GNSS over MBIM.
Actually, if the service is going to
> transfer huge amounts of data within MBIM indications, it probably
> makes more sense to them to setup a specific DSS session for that,
> instead of overflowing the main MBIM communication channel.
Agreed and we did try to convince them of that and hopefully this will be
implemented in the future.
> Also, what
> about other unknown services which may expect to have clients listen
> to the indications even when the service was not used in advance?.
Yeah, I was pondering that too, but since the spec I was working with
specified that the indications were turned on and off I mistakenly assumed
it was standard as part of the MBIM spec.
> I'm not sure if that's true in MBIM. It is in QMI; i.e. a client can
> register to get notified about a given indication, and can unregister
> when it no longer wants them. In the case of MBIM; receiving
> indications is not something we can choose or not choose, I believe.
> So, by default we should forward all indications.
Yeah, now that I went back to look at the spec, you're right.
> Another thing, though, is whether we want to include an additional
> private command in the proxy service to let clients register or
> unregister to some indications. If the client wants to get notified
> about only a subset of indications, we can setup a new open-flag to
> request that, so that it can then "subscribe" only to the indications
> that it wants. Given that this is to be handled by the proxy (i.e. the
> communication with the device will still handle all notifications), it
> can just be seen as an addon, same as the proxy is. The only problem
> with this approach is that then, we're kind of forcing standard
> clients to use this logic, so that they don't get bothered with
> indications they don't know of...
I was thinking about doing that too but limit the indication registration
non-standard services. So standard clients won't require any change.
I would prefer this solution over forwarding all indications, purely for
A mbim_device_register_custom_service() could be added which would then call
mbim_register_custom_service() and send the private command to the proxy.
Same would be done for unregister.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libmbim-devel