Moving libqmi-glib to fd.o's libqmi repo

[Marcel Holtmann]

Hi Aleksander,

> I am going to prepare to move libqmi-glib from gitorious.org directly
> into the libqmi repo at fd.o.
> 
> In this process, I was going to rename it from libqmi-glib just to
> libqmi, but don't have a strong feeling on this. If anyone is willing to
> develop a glib/gobject/gio-free version of libqmi, just speak up and
> I'll keep the -glib suffix. Anyone willing to do so can already benefit
> from the codegen I guess, just modifying the codegen to generate
> glib-free code. Actually, I may just leave the prefix anyway, in case
> someone shows up in the future willing to do so.

actually there is a libqmi in the Chromium tree:

http://git.chromium.org/chromiumos/platform/libqmi.git

And we already have developed a GObject/GIO free version of QMI support
for oFono.

http://git.kernel.org/?p=network/ofono/ofono.git;a=blob;f=drivers/qmimodem/qmi.h;hb=HEAD

However there is no real plan to turn this specific code into a real
standalone library. It is just the basic QMI transport, control point
and service discover handling. And it is tiny:

 1938 drivers/qmimodem/qmi.c
  152 drivers/qmimodem/qmi.h
 2090 total

Maintaining a separate project and library for that seems total
overkill.

I looked deeply into all areas of QMI services. Trying to create a fully
bloated library with API support for all services is a waste of time. At
least for oFono it is useless. The problem is that QMI itself is deeply
service context sensitive and there is no point in creating another
abstraction on top of it. I decided to just put the service specific
handling directly into the oFono drivers. Have a look at the code for
yourself, it worked out super nicely for us.

There are also deprecated QMI commands and different versions of certain
services. To handle them properly, you need to understand the service
itself and know to handle it or fallback if needed. The first one where
you will see this issue is NAS with the network selection and attach
handling. Gobi 2000 differs clearly from newer cards here.

And on that note, I think you will soon reach serious limitation with
the code generation idea. The advanced QMI data structures are not
funny. Have you actually looked into NAS or UIM services? You get some
nice variable length strings and variable length structures embedded in
the middle of other variable length structures. Or you have TLVs that
extend the data structure, or replace others. In addition newer QMI
services are heavily subscription based with their indications.

Regards

Marcel