When to allocate client IDs
jglasgow at google.com
Mon Mar 26 06:58:33 PDT 2012
On Mon, Mar 26, 2012 at 7:37 AM, Bjørn Mork <bjorn at mork.no> wrote:
> I'm looking at this:
> and wonder if it wouldn't be better to do on-demand client ID
> allocations? I think it's safe to assume that not all applications will
> need all subsystems. And we know for sure that not all devices support
> all subsystems. So attempting to allocate IDs for all of them is
> guaranteed to create unnecessary overhead.
This was modeled after the qualcomm SDK. We already know that gobi3K
supports more subsystems than gobi2k. We (and the qualcomm sdk) have just
been ignoring errors for subsystems that don't exist.
> And then there is the weird device issue. I've already seen one example
> of a device supporting some of these systems, but failing (modeswitching
> and thereby disappearing) when attempting any QMI_WDS commands. This
> device did survive the QMI_WDS client ID allocation, so all this may be
> totally irrelevant. But still, I wouldn't be surprised if some other
> device went bananas when it got a request for an unsupported client ID.
That would be a particularly poor behavior to fail catastrophically -- but
I agree that such a behavior is possible.
> The point is that an application may have a lot more knowlegde about a
> particular device, such as supported subsystems, and if you allocate the
> IDs on-demand then the application can work around any issues by just
> avoiding the known unsupported ones.
Good point. Of course the library could also be smart about which modems
support which services. It seems like a better place to keep some of this
> Another point is that most subsystems will start sending you unsolicted
> notifications once you allocate a client ID. That's of course nice as
> long as you are prepared to handle them, but useless noise if no
> application is interested.
I thought that one had to explicitly register for the unsolicited
notifications. That seems to be the case for subsystems (RFInfo callbacks
for instance), but not others (SesssionState callbacks). So this is a good
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libqmi-devel