[RFC] libqmi without glib2 and qmicli JSON output

[Alexandru Ardelean]

On Fri, Sep 29, 2017 at 11:30 AM, Aleksander Morgado
<aleksander at aleksander.es> wrote:
> Hey,
>
>>
>> 1. Background:
>> OpenWrt/LEDE, has uqmi package, hosted here:
>> https://git.lede-project.org/?p=project/uqmi.git;a=summary
>>
>> That package is very tiny and works with some QMI modems.
>> I only tested with Sierra MC73xx.
>>
>> But for MC74xx, I've hit some limitations that I've eventually found
>> explained here:
>> https://bitbucket.org/aleksander0m/ravemodemfactory
>>
>> So, now I've ported libqmi to OpenWrt/LEDE, and wrote a proto handler
>> for OpenWrt/LEDE's
>>
>
> Any pointer? I actually already did that a loooong time ago myself
> ("qmi4g" protocol handler IIRC).
> https://sigquit.wordpress.com/2012/08/20/qmi-powered-broadband-connections-in-openwrt/
>
> Also, have you also seen this? It contains libqmi, libmbim and
> ModemManager using a new custom protocol handler as well. All using
> glib2 though.
> https://bitbucket.org/aleksander0m/modemmanager-openwrt
>
>> 2. The point (1) - libqmi without glib2
>> glib2 is a bit big for OpenWrt/LEDE
>> I have started trying to write glue-code to remove it, but I don't
>> have time atm to go all the way.
>> But I will try to make some time later for this.
>>
>> Question is: would it be reasonable to add a option to the ./configure
>> part to do ./configure --with-internal-glib-code [ or whatever name
>> works ] ?
>> I'll do the work ; just want to know if this would be acceptable.
>>
>
> I'm not sure you realize how much effort this would be :) glib2 isn't
> just a "helper" library, the whole libqmi-glib is based on using the
> GLib main loop, GObjects, Signals, Asynchronous methods...

Yeah, I saw the Glib main loop & stuff.
[ I still sometimes like to keep my naiveté ]

>
> Some years ago I started a "libembim", introducing a glib-less API
> equivalent to libmbim, but didn't finish it and I spent quite some
> time with it... Got the branch somewhere.
>
> All that said, yes, I wouldn't mind to have a glib2-less libqmi, but
> leaving libqmi-glib as it is now. i.e. A new 'libeqmi" (e for
> embedded) could be written.
>
uqmi uses a lot of libubox for this stuff [which has uloop for
main-loop and some other stuff ] ;
uqmi actually copied libqmi stuff and re-did some build stuff, and did
the linking to libubox events/stuff
what i don't like about uqmi is the fact that CLI params are different
that qmicli
also, it's not as maintained as libqmi [since it's secondary effort of
OpenWrt/LEDE]
while i can alloc time to make that stable/work for me, mid-to-long
term it's a parallel effort

libeqmi sounds very reasonable, if maybe we can make it an official
element of libqmi ;
so maybe have  libeqmi side-by-side with libqmi-glib ; or another repo
? [ both work for me ]

for libeqmi I would be tempted to use libubox, because it's an
external lib of OpenWrt/LEDE
that just wraps epoll and some other timers/events in a neat/easy way;
i don't mind re-implementing a new epoll loop ; will see;

> The new library should clearly separate two things:
>   * APIs to build/parse QMI messages (something libqmi-glib could
> re-use easily).
>   * APIs to control clients and devices.
>
> The latter requires clearly defining how the asynchronous operations
> will be done, and this is the hardest part to get right. Do we use
> internal threads? Do we use some extra library like libevent? Or just
> some generic APIs to let the user define how the async polling and
> events will be handled? All these questions should better be answered
> before trying to do any port, IMO.
>
>> I agree we can't get rid of glib2 completely ; for OpenWrt/LEDE we
>> have to build a host glib2 so that I can convert the .json definitions
>> to C code [and that is perfectly fine].
>> But for the target build [ that gets installed on the device ] I would
>> prefer to not install glib2.
>> And sure, maybe it's a futile effort, but I'd still like to try.
>>
>
> There's no need for host glib2 to convert the JSON definitions to C
> code, this is just a python program doing it.

I think I noticed some Python stuff/scripts but I needed to define
   GLIB_MKENUMS=$(STAGING_DIR)/host/bin/glib-mkenums
I did not dig too deep to be sure if this can be non-needed.

>
>> 3. The point (2) - qmicli JSON output
>> Some OpenWrt/LEDE scripts/commands output JSON.
>> And there is a very neat way [in the eco-system] to work with JSON in shell.
>> I would also like to output JSON output [of course, me doing the work].
>>
>> Parsing JSON in OpenWrt/LEDE is way nicer than running sed,awk,grep
>> commands to get the value I want.
>> Especially when output is verbose, and I want 3 values of 20.
>>
>> Is this [also] something that's reasonable ?
>>
>
> Oh, this is orthogonal to the no-glib2 issue. I'd love to have
> something like this actually, and I believe there are patches out
> there (in github?) from some other dev that already started to do
> that. Same for mmcli and mbimcli outputs, if you're up to it :)

interesting; will check it out
if you remember where it is, please point me

if not, i can try to find it or implement it from scratch

maybe I'll consider doing something generic ;
i have a preference for json-c  ;
will see

thanks :)

>
> --
> Aleksander
> https://aleksander.es