[RFC] libqmi without glib2 and qmicli JSON output

[Aleksander Morgado]

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...

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.

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.

> 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 :)

-- 
Aleksander
https://aleksander.es