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

[Aleksander Morgado]

Hey,

>>>>> 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.
>>>
>>
>> Well, just representing the request/response of a message in JSON with
>> 20-30 lines, I get the service-specific QmiClient extended with a
>> complete new async method ready to be used, including code to handle the
>> input and output TLVs it expects. It's really really handy.
>>
>> See for example the PIN Change request/response:
>> https://gitorious.org/lanedo/libqmi-glib/commit/19316ab610241d33d5eacfb837f50d6f153130ee
>>
>> And how qmicli uses the generated qmi_client_dms_change_pin():
>> https://gitorious.org/lanedo/libqmi-glib/commit/b9290d715048d75f0651bd0c55300fa1b07692ad
> 
> I still fail to see on how that all works out when you have the really
> complex structures. And what the benefit is here. Since essentially you
> end up with a lot of copying of data. I am already disappointed that
> Qualcomm decided to save one byte and not use null terminated strings.
> That kills all the nice zero-copy we are doing otherwise.
> 

You surely can (try to) do zero-copy when you embed all the message
processing within the application itself, just read the values directly
from the raw buffer and use them. But, when trying to write a library to
handle all these, with all its implications, you definitely need some
additional layer to pass in/out processed values, that's what I at least
am trying to do with libqmi-glib. If this extra layer allows multiple
users of a single implementation, even with some additional structs and
copies, I'm quite happy to have it.

> Have you looked into how to deal with CAT 1.0 vs CAT 2.0. They gave them
> different service identifiers. Or is SIM Toolkit not interesting for you
> guys at all? I know that we care about it.
> 

>From the library POV, I guess we can assume those are two completely
different services, and that's it. Users of the library can then decide
what to use.

>>>>> 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.
>>>
>>
>> Hum... so a given TLV with a specific ID gets updated between versions
>> without updating the ID as well?
> 
> It is possible. Some other times you get a different indication or you
> have other commands to use. Or a new service even. As I said, so far
> that applies to NAS, Voice and then DMS vs UIM.
> 

Having different indications, other commands or new services is all
problem of the user of the library, not a problem of the library itself.
At least as long as we only have a low-level version of it. As I said
earlier, whenever we have the low level bits in order, we can try to
provide a higher level API which can decide which
command/service/indication to use based on the initial version-info
check. I'm not saying this will never happen, just that first we'll need
to handle the low-level bits first.

Cheers!

-- 
Aleksander