Consider using libqmi JSON definitions?

[Ed Wildgoose]

Hi, I wrote an elixir wrapper around qmicli from libqmi. It works quite well (I will surely get around to opensourcing it real soon, especially if there were volunteers to help improve it?). However, I wanted something direct in elixir, especially as the protocol is quite straightforward

However, when I look at the code in nerves, I'm not sure that I understand what I'm seeing? There seems to be custom parsing functions for each QMI function we can call, despite that we can potentially automate much of that parsing (because the response and call are TLV params)? I wonder if you are aware of the JSON description files that are used to generate much of libqmi C code, here:

https://github.com/freedesktop/libqmi/tree/master/data

I concede that whilst I'm pretty sure we can do some magic with macros to take this json and use it to generate functions to call and parse the QMI functions/responses, I also concede it's above anything I've tried so far...

So Q. Is there any interest to create a low level "codec", which is autogenerated from libqmi definitions?

Note that I expect on top of that to need to add a higher level API which translates some of these values, ie as is qmicli to libqmi. Many of the low level responses benefit from scaling, translating, coalescing, etc

Any thoughts? Also, is there a mailing list that would be a more appropriate place to discuss this?

[Frank Hunleth]

Hi - sorry for the delay in responding.

The quick answer is yes we're aware of the JSON description files, and no, we have no plans to switch to autogenerate the code. The history of this project is that we weren't sure how we wanted to structure the code when we started and put off implementing automatic generation. The reason we have no plans is that we actually need to move away from QMI to USB ECM-based modems. We still have tons of QMI-based modems in use and will continue to add small features as needed, but I doubt that we'll have time to implement auto-code generation ourselves. Having said that, I do agree that there's a lot of benefit in automatic code generation if we weren't too inconsistent with our manual code generation.

I should also point out that there's another QMI project that we didn't find out about until it was too late for us to change course. It's https://github.com/nadsat/eqmi.

[Ed Wildgoose]

Aha, thanks for the link to eqmi! I guess that would be an obvious thing for you to migrate this module to use as it seems to pull the whole JSON descriptions from libqmi?

You have now raised another question though... When you say switching to ECM based modems, can you describe what you mean and what you envisage your plan is here? (And is there a better place to ask these questions than this issue tracker?). To state my misunderstanding, I thought that QMI was ECM + signalling? (And in contrast MBIM is NCM + signalling?)

I've got to support a boatload of modules in an embedded setting and at least watching openwrt, and Quectel/Sierra Wireless, QMI seems better supported by default and equally or more performant than MBIM? I don't know if mbimcli simply doesn't support all possible commands, but I don't really see enough commands to do much of what I want there (so will need to patch some commands in with AT stuff)

Despite many years of standards moving sideways I don't see there is a winner here? It seems like any daemon likely needs to support a hybrid AT+QMI/MBIM approach for a little while yet (a la modemmanager I guess?). Have you any designs in that direction?

It's not always easy to see how to get involved with development in nerves libraries? For various reasons I can't use nerves directly, but I have an IOT use case and need to solve most of the same problems. However, I frequently struggle to see how to get started on cooperating with patches as many of the libs are quite tightly bound to your chosen infrastructure? Any tips?