Proxy for QMI messages

Aleksander Morgado aleksander at
Tue Jul 9 04:16:26 PDT 2013


As you already know, currently only one application can use a given QMI
port. If MM or ofono are running, qmicli won't work, and viceversa. In
the original Code Aurora kernel driver, it was the kernel itself taking
care of QMI client allocation, and it was the kernel itself the one
handling QMI messages from multiple applications. In our case, this is
not possible, so if a connection manager is running, you e.g. cannot
have an application which wants to run specific NAS commands to query
signal or RRC state.

So, how about building a new "qmid" daemon which takes care of
reading/writing in the QMI port, and let all applications send/receive
QMI messages through this proxy qmid? Applications would still build the
QMI messages themselves, and the only thing they would need is to
allocate/release QMI clients with the daemon. This change could be done
deep in libqmi-glib, so that the interface is kept unchanged while the
internals now go through the qmid proxy. Also, this change could even be
optional through configure (e.g. enabled for distributions, but disabled
if building a custom system and this is not needed).

Having a setup like this could yield to new problems, though. Like,
qmicli commands which change the state of the modem but MM not
refreshing that new state.

What do you guys think?


More information about the libqmi-devel mailing list