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

[Marcel Holtmann]

Hi Aleksander,

> > 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.
> 
> Sure it did, but we really want to have a library here, instead of 
> having everyone implement the message-specific logic over and over.
> 
> >
> > 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.
> >
> 
> The library is willing to support all QMI commands; it just provides a 
> user-friendly interface to use those commands, assuming they are 
> available. Given that we allow to run a version-info check during the 
> QmiDevice opening, we may in the future tag each command with the 
> specific version where it was introduced, and provide some more higher 
> level logic which will use one command or the other based on the current 
> available service versions. Out of the scope of the library right now 
> anyway, clients should for now handle that themselves.

if you just implement all low-level service commands, then what is the
difference of just having a simple generic way of dealing with QMI
services like we do. It seems it is providing the same features, just
with a more complex API on top of it. Not sure if that is actually
helpful.

> > 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.
> >
> 
> Variable-length members on variable-length structs/arrays are no longer 
> a problem since we do not create packed struct templates to cast the raw 
> buffer, the generated code now reads the expected elements one by one.

You should check with UIM service and some of PDS service structs and
see if that all still works for you. Some of them are seriously crazy.

> For the different TLVs, extending the data structure or replacing 
> others, we're just fine as long as the existing TLVs are not modified 
> (this is, the new ones get a new TLV ID).

In general they do. See the scan results where they added an extra TLV
for the missing RAT information.

However with Voice service there are different between major versions.
So I think the assumption can only be made per major version of a
service.

> As for the indications, the idea is to implement signals on the 
> QmiClients which will be emitted when the indications arrive, so that 
> users of the library need just to connect to them once they have enabled 
> the indications via request/response.

You do know that most indications vary on which TLVs they include
depending on what is enabled or what happens in the system. Since
individual TLVs can be enabled individually.

Regards

Marcel