Purpose of gobi SDKs inside the directory gobi-api

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:
> On Mon, May 12, 2014 at 9:34 AM, Daniele Palmas <dnlplm at gmail.com> wrote:
>> maybe a silly question, but which is the purpose of all the gobi SDKs
>> inside the directory gobi-api?
>>
>
> They are just there for reference.
>
>> Has one of these SDKs been patched for working with the qmi_wwan driver?
>
> Nope, no.

And if someone really want support for the Gobi SDK with the qmi_wwan
driver, then I propose a userspace proxy application providing the
/dev/qcqmi character device expected by the SDK.  That seems more
future-proof than creating a special SDK version.

This will be a hassle to create, for much the same reasons the Gobi
driver didn't quite make it into the kernel despite Elly Jones'
excellent rewrite: You need to handle CID allocations using an ioctl.
That rewritten driver is still the best documentation of the API:
https://lwn.net/Articles/410427/

I believe it is possible to implement this in userspace using CUSE, and
possibly taking full advantage of libqmi with the qmi-proxy.  Hmm, there
isn't really much CUSE docs around.  The best reference I found is the
example from the FUSE docs:
http://fuse.sourceforge.net/doxygen/cusexmp_8c.html

The reason you need CUSE is of course the private ioctls being used by
the Gobi SDK API.  A simple file/pipe/whatever/FUSEfs won't do.

Why not a dedicated Gobi SDK API "shim" driver?  Well, I did write one
for fun.  It was too ugly to live, having no chance ever getting into
mainline.  Not a good idea at all.  Will not be published anywhere.


Bjørn