Reg bringing up libqmi

[Marcel Holtmann]

Hi Aleksander,

> >> > I am trying to bring up libqmi in a embedded residential gateway product.
> >> > 
> >> > Please let me know if there is any light weight libqmi source, since i will not be able to install the required packages, glib in my product.
> > inside oFono (drivers/qmimodem/qmi.c) we have a lightweight QMI library.
> > It still uses GLib, but only its core library for the mainloop and basic
> > data structures. So no GObject or JSON.
> 
> JSON in libqmi is just required during compilation, to generate the
> source code.
> 
> GObject-based sources were a nice addon to easily handle the
> communication with the QMI device (e.g. signals for indications), and it
> integrates well with ModemManager and others (e.g. via introspection).

I am always worried about the extra overhead of such things like
GObject, but nevermind.

> The guys at OpenWRT are working on a C-only based library which would
> help to create/parse the QMI messages, using a modified code generator
> and our JSON database, and targeted to be included directly within the
> applications (i.e. no API stability or anything). That really makes a
> lot of sense to me, for e.g. embedded applications not wanting to use
> glib and friends.

Good for them. Hope it works out.

> > If you really want to use QMI properly, then only an integration into a
> > real telephony stack makes sense. I never considered a standalone QMI
> > library a good idea. Same as nobody really has a standalone library for
> > just handling AT commands. 
> 
> A standalone QMI library itself, and actually every library, is stupid,
> of course, unless a connection manager or other application uses it :)
> libqmi is used by both qmicli/qmi-network and ModemManager (and possibly
> Python-based connection managers soon through GObject introspection).
> 
> Also, libqmi is not only about reusing code, it's about making it easier
> to use the protocol by hiding all the logic to handle
> request/responses/indications. The libmbim I'm writing these days for
> MBIM goes even further and handles transparently all message
> fragmentation requirements, which is nice. Why does everyone have to
> write its own QMI handling code within the telephony stack in order to
> "use QMI properly"?

So QMI and MBIM should be libraries, but AT commands are not. That is
kinda funny. But then again parsing AT commands with regular expressions
was never a good idea to begin with in my book ;)

> Also, I very much prefer a code generator giving me all needed sources
> to parse and create really complex messages with TLVs including arrays
> of structs with other arrays inside for example, than writing a custom
> parsing for each new such TLV I find... e.g.
> 
> http://cgit.freedesktop.org/libqmi/tree/data/qmi-service-dms.json#n971
> 
> Of course you still need to then integrate the logic in your own
> connection manager, but at least I don't need to write the parsing code
> for that message.

If you think DMS is complicated, then you might look into UIM. That is
the one that Qualcomm really screwed up. And if you ever move away from
a simple Internet only connection manager into a real telephony stack,
then UIM is what you need. The Gobi 2000 cards without UIM service are
actually painful to deal with. Their exposed services are not giving you
enough access to low-level details.

UIM service is the one where Qualcomm engineers should have taken a
lesson in what TLVs are really for and how you could use them, but they
decided not to.

Anyway if your basic message structure is TLV based, then I never
understand why you would pre-parse everything into other memory
locations and waste the memory. Especially if you do not know what the
application requires in the end. That is why a like the context specific
parsing of the messages. I can take the pieces I need and ignore the
rest. Even if I know how to parse them. Which means I have less memory
to allocate for each message that I need to parse.

> > So for oFono its all fully integrated and
> > that helps a lot when you reach the point of having to deal with the SIM
> > filesystem, SIM Toolkit or SMS.
> 
> I understand that if you're targeting custom embedded systems you don't
> want a generic implementation and you may want your own, e.g. only
> implementing the messages you really need. That's fine, and wise. Now, I
> don't know how exactly that helps in dealing with e.g. SMS. How does a
> fully integrated custom implementation help with that? Just wondering.

The SMS part is still sort of simple in QMI, but has some nasty bits
with the message routing when you want to run it in a telephony stack.
Just in case anybody cares, but then again ModemManager still thinks
that managing messages on the SIM card is a good idea ;)

Look into UIM and CAT services if you want to see something nasty.

Regards

Marcel