running libqmi on Android / qmuxd

[Aleksander Morgado]

Hey hey Harald,

On Sun, Dec 18, 2016 at 10:58 AM, Harald Welte <laforge at gnumonks.org> wrote:
> I know how to access qmuxd and have soem early proof-of-concept code to
> e.g. obtain the IMEI via it.
>
> So what I'm asking for is an idea where it is best to split libqmi and
> create a Frankenstein-backend that talks to qmuxd, rather than to a
> /dev/cdc-wdm device
>
> The goal is to have the 'upper layer' from libqmi, together with some
> free softwre glue code to talk to qmuxd, and thus be free of linking or
> includign any proprietary qualcomm bits.

All the logic managing the client allocation/deallocation and all that
is done by the GobiNet driver in the kernel (when using Qualcomm's
driver) or by our libqmi in userspace (when using qmi_wwan), using the
QMI CTL Service. When using libqmi, the whole logic of the "CTL
service" is hidden within the QmiDevice implementation. A user of the
API has methods to "allocate a client" or "release a client"; how that
is done is totally hidden. This is a key point, because that allows us
to not just talk to the /dev/cdc-wdm device to issue QMI CTL commands;
it also would allow us to allocate and release client ids in whatever
way we need (e.g. we could do ioctl()s on the /dev/qcqmiX exposed by
GobiNet, or talk to qmuxd).

I don't know much about how the qmuxd operation goes on, but if you
already have working code doing QMI DMS operations it shouldn't be
very hard to implement a QmiDevice subclass that uses the qmuxd
backend, or just extend the QmiDevice we have with some additional
logic, like we did for the qmi-proxy operation (where the QmiDevice
talks to a daemon listening in a UNIX socket, instead of directly to a
/dev/cdc-wdm device).

-- 
Aleksander
https://aleksander.es