How other applications use the ports that occupied by MM

[Ben Chan]

On Thu, Mar 21, 2019 at 9:25 AM Aleksander Morgado
<aleksander at aleksander.es> wrote:
>
> >
> > Yeah, mixed feelings from me too. I guess before we do that, can we ask
> > what commands people want to use? I'd rather it not be used a short
> > circuit for stuff that could be fixed in MM or implemented fairly
> > easily for a device. That's my only reservation, that having it may
> > reduce the incentive to fix/enhance MM itself.
>
> Speaking here as a user, I've been in the need of running AT commands
> sometimes as well, e.g.:
>  * To enable/disable istp traces in Intel-XMM based devices.
>  * To query the status of totally unrelated things, e.g. audio profile
> settings, for which we will probably never have MM APIs.
>  * To query the status of routes configured inside the modem, e.g
> AT+UIPROUTE in the TOBY-L4.
>  * To query device-reported temperature, although for that I could
> envision a "temperature" interface or something like that.
>  * For module certification purposes, or e.g. to show the current
> status of the modem to people who "speak the AT protocol" but who
> don't necessarily understand how MM or mmcli work.
>
> Sometimes I've also seen people running mmcli --command for things
> that would break the MM flow, e.g. running CFUN=4 and CFUN=1 manually
> via --command, and that really messes up all the MM logic indeed, but
> that is honestly the same mess that could happen after running qmicli
> set operation mode offline/reset manually.
>
> As long as the user understands that the API should be exclusively for
> "reading state", all should be good... "should".

I also have mixed feelings (probably more negatives than positives)
about that. It comes handy for debugging and manual queries as you
said, but opens up the possibility for other applications to misuse or
abuse it. For modems that expose a single AT port or have an AT port
for both modem and non-modem (e.g. GPS) functionalities, I'd imagine
how problematic it could be.  I guess we could use D-Bus policy to
restrict who can use Modem.Command, but that may not be granular
enough. A compile-time configuration, as you suggested, would be
great.  On a related note, I really hope and look forward to one day
when we only need the generic MM plugin with MBIM / QMI support to
support any modem :)

>
> --
> Aleksander
> https://aleksander.es
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel