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

[Giacinto Cifelli]

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