How other applications use the ports that occupied by MM

[Dan Williams]

On Mon, 2019-03-18 at 11:24 +0100, Aleksander Morgado wrote:
> Hey,
> 
> > I am trying to find a way to use the AT ports or mbim ports that
> > occupied by MM as all the device ports were used by MM. eg. I want
> > send AT command to the modem, but MM occupies the AT port. Is there
> > any way to make MM stop using the AT port for a while but not kill
> > the MM? To do that, maybe the application can send a D-bus signal
> > or request a method to MM, then MM stop the AT port for a while,
> > after application finish its work, send a D-bus info to MM, MM
> > continue use the AT port.
> 
> If the AT port is not the primary control port, you could add the
> ID_MM_PORT_IGNORE udev tag on the specific TTY so that MM ignores it.
> 
> > And I know in MM debug mode, mmcli could use --command  to send the
> > AT command. Is there normal mode way to send AT command from MM?
> 
> Right now --command only works while in debug mode, so that the user
> doesn't send commands that may interfere with the control logic of
> MM...
> 
> But truth be told, we're already allowing QMI and MBIM commands to be
> sent through the proxies while MM is running anyway...
> 
> @Dan Williams what would you think if we open up the Modem.Command()
> method also while not in debug mode? We could explicitly warn that MM
> will treat all these commands as transparent, so if the state of
> modem
> changes as a result of these commands, MM may get out of sync.
> Another
> option I'm thinking about is to make it a configure option instead.
> Don't know, mixed feelings.

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.

Dan