Proxy for QMI messages

Bjørn Mork bjorn at
Tue Jul 9 10:10:07 PDT 2013

Aleksander Morgado <aleksander at> wrote:
>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
>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
>optional through configure (e.g. enabled for distributions, but
>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?

 I think this is a great idea. Especially if the interface access is handled seemlessly by libqmi.

As you are probably aware, one early incarnation of qmi_wwan implemented something like this in the kernel. But it had to go to make the driver protocol agnostic. And I'm glad it did. This does not belong in the kernel.

You are probably also aware of the android qmi proxy implementation? I haven't looked closely at it, but assume it's close to the Code Aurora driver since the origin is most likely the same.


More information about the libqmi-devel mailing list