Idea to have qmicli output "parseable" data

[Jack Broderick]

Hi Ed,

I have had this exact same question before. There is a MR
https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/190
that does exactly this. I have not made contributions to it so I don't want
to take credit for it but I'm quite excited for when it is merged!

Cheers,
Jack

On Tue, Jul 27, 2021 at 8:21 AM Ed W <lists at wildgooses.com> wrote:

> Hi, I needed to access details of my modem via Elixir and I have a future
> requirement to do similar things via Lua. However, it seems more than a
> small hurdle to get access to libqmi from any scripting languages?
>
> My first thought was to adapt qmicli, which largely does everything I
> need, but to patch the output to be optionally JSON or similar. However,
> the coding style of qmicli, doesn't easily lend itself to this kind of
> change. The issue is that, at present, whilst many commands could be
> adapted, many others generate bits of string data dynamically in response
> to nested conditionals, etc.
>
> So, because it's a potentially pretty large change, how much interest is
> there to adapt the qmicli app to instead of generating direct string
> output, to instead generate some kind of nested structure (map), which will
> then either be kicked out as text (identical to present), but can also
> optionally be converted to something hierarchical and parseable, such as
> json/xml/toml, etc?
>
>
> In the meantime for my elixir library I took a stab at simply parsing the
> text which comes out of the current qmicli utility. It's largely indented
> into a structure and so (largely), by counting tabs at the beginning of the
> line one can fold it back into some kind of structure that makes it easy to
> process in a given scripting language.
>
> However, there isn't absolute consistency in the format of the output, for
> example, compare:
>
>     /usr/bin/qmicli -p -d /dev/cdc-wdm0 --nas-get-serving-system
>
> and most other commands, eg
>
>     /usr/bin/qmicli -p -d /dev/cdc-wdm0 --nas-get-signal-strength
>
>
> The output from nas-get-serving-system is all shown with an extra level of
> tab indents (ie indent level starts at 1), whereas most other commands are
> left aligned, ie indent level of 0 starts at 0.
>
> Another (minor) challenge is that errors/status messages are not
> completely homogeneous, eg a general error in params causes output to
> stderr and I think a non zero return code(?), however, status messages
> relating to a command where the params are ok shows all results on stdout,
> with the qmi data "mixed in" with the status messages from the utility. eg
> the first line of most messages, or the trailer if you add
> "--client-no-release-cid"
>
> Another curiousity is the output if you call "--client-cid=xx" with an
> invalid cid, this spits out an error immediately, but the app doesn't exit
> for another 10 seconds with a further timeout message. (from memory one to
> stdout, one to stderr)
>
> So not withstanding all of this, I can do the following in my elixir app
> (which actually works quite well for my needs):
>
>
> iex> Exqmi.qmicli(nil, "nas-get-serving-system", device: "/dev/cdc-wdm0")
>
> {:ok, "Successfully got serving system",
>  %{
>    "3GPP cell ID" => "283456",
>    "3GPP daylight saving time adjustment" => {"1", "hours"},
>    "3GPP location area code" => "65534",
>    "CS" => "attached",
>    "Current PLMN" => %{
>      "Description" => "voda UK",
>      "MCC" => "234",
>      "MNC" => "15"
>    },
>    "Data service capabilities" => %{"0" => "lte", "_value" => "1"},
>    "Detailed status" => %{
>      "Capability" => "cs-ps",
>      "Forbidden" => "no",
>      "HDR Hybrid" => "no",
>      "HDR Status" => "none",
>      "Status" => "available"
>    },
>    "Full operator code info" => %{
>      "MCC" => "234",
>      "MNC" => "15",
>      "MNC with PCS digit" => "no"
>    },
>    "LTE tracking area code" => "12345",
>    "PS" => "attached",
>    "Radio interfaces" => %{"0" => "lte", "_value" => "1"},
>    "Registration state" => "registered",
>    "Roaming indicators" => %{"0" => {"off", "(lte)"}, "_value" => "1"},
>    "Roaming status" => "off",
>    "Selected network" => "3gpp"
>  }}
>
>
> Basically the output is really close to being parseable without too much
> trouble. However, it feels like a change in how the messages are generated
> in the first instance, could lead naturally to a final output step that is
> capable of spitting out the result in a variety of forms. I'm not really
> familiar with what tools we already have in glib, but perhaps it already
> has a structure (map?) that we can put the messages into at construction
> time? ie I'm looking for the smallest change possible, ideally something
> that can be automated given the amount of code that would be touched.
>
> Any thoughts?
>
>
> Ed W
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20210727/1266dffe/attachment.htm>