[RFC] Exposing profiles (provisioned contexts) in the API

[Eric Caruso]

Hi all,

I picked the single property for the initial implementation so that MM
would notify consumers when the profiles list changed via OTA update.
If we are moving to a D-Bus method to list them instead, then we
should preserve this behavior somewhere else (i.e. a separate signal).
Chrome OS should be able to handle OTA updates properly as long as we
have that.

Regarding the "set option" I had also specified D-Bus methods for some
other operations (create, modify, delete; creating a bearer from a
profile) but these were never implemented as the modem I was using had
a firmware bug that caused issues when I was testing it. After that I
was pulled away for other work and unfortunately never got to pick
this back up.

-Eric

On Tue, Jan 12, 2021 at 6:53 AM Giacinto Cifelli <gciofono at gmail.com> wrote:
>
> Hi Aleksander, all,
>
> for Cinterion modems that support the profiles, there is a special
> command to read them (ATI61, no mbim equivalent, maybe qmi but I
> wouldn't know it; and an at^scfg? option to read the current one) as a
> list and would fit well with option 2.
> The second option would also sit better in the context of a get/set
> option, because clearly option 3 wouldn't set it globally, and option
> 1 would be just informative.
>
> For Cinterion modems, the profiles have been experimented with for a
> few years, so old modems restart when a new profile is selected (for
> example, the PLAS9-X).
> Also, for all Cinterion modems supporting profile selection, they are
> normally in automatic mode and the property is indeed read-only.  It
> becomes writeable by changing the flag automatic/manual.
>
> I don't know exactly how other manufacturers work, but there are
> chances that it is implemented in a similar way, because the profiles
> were introduced by the chipset manufactures (initially) to deal with
> the various VoLTE flavours.
>
> Best Regards,
> Giacinto
>
>
>
> On Tue, Jan 12, 2021 at 11:30 AM Aleksander Morgado
> <aleksander at aleksander.es> wrote:
> >
> > Hey all,
> >
> > Eric wrote an initial draft of the API to expose profiles (provisioned
> > contexts) in DBus here:
> > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/179
> >
> > The initial implementation he wrote relies on a read-only "Profiles"
> > property exposed in the 3GPP interface, with signature "aa{sv}" (an
> > array of dictionaries).
> >
> > A second option would be to have a new ListProfiles() method instead
> > of a read-only property, which is e.g. equivalent to what we already
> > have for the list of available firmwares installed in the
> > Firmware.List() method.
> >
> > A third option would be to promote the profiles to actual DBus objects
> > exported (as with SMS, Call, SIM...). This is maybe too much?
> >
> > For some context, these profiles could be loaded initially on modem
> > initialization, but they can also be asynchronously updated by the
> > modem itself (and could be reported to us via indications, as e.g. in
> > MBIM), or manually updated by us with the new methods we would add. My
> > only concern in this logic is that there may be some protocols where
> > these profiles are updated in the modem and not notified to us
> > actively via indications. In this case, I don't think how options
> > 1(the property) or 3 (the per-profile objects) would fit correctly, we
> > would end up not reporting up-to-date info. Only option 2 (the
> > explicit ListProfiles() method) would make sure that whenever the user
> > needs the list, this list is up to date (as we would list the profiles
> > at that exact time).
> >
> > What do you all think?
> >
> > --
> > Aleksander
> > https://aleksander.es
> > _______________________________________________
> > ModemManager-devel mailing list
> > ModemManager-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel