Promoting MM for another embedded consumer distro (how to?)

[matthew stanger]

Hey MM,

One time contributor, long time lurker here.

TLDR: I'm seeking input to help champion MM as a core cell management
component
to a large firmware collaborations body. If successful, IMHO, it'd have huge
benefits to WWAN/Linux wireless & MM as it'd bring in a lot of official
support, more WWAN standardization, and muscle to the community.


Here's the situation.

We're working with the RDK community to add Fixed Wireless Access support to
the project. If you've never heard of RDK before it's basically like Android
for STBs & modems (rdkcentral.com/rdk-profiles/)[+80 Million deployments].
Chances are if you have a modem/STB in the US or EU it runs this software.
So
why does this matter to MM?

Getting MM in this distro would bring in a form of direct support to
libQMI/libMBIM from the two silicon makers and a small army of developers.
It
would help reinforce QMI/MBIM as standards across the WWAN industry and
enhance feature/quality for those libraries and MM.

Currently there is debate on the best solution/architecture for RDK for cell
support (data-only modems). While I champion for the full MM + libQMI/MBIM
stack many want to only use libQMI/MBIM and propose a custom but technically
FOSS RDK cell manager
(
https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/RdkCellularManager/+/refs/heads/rdk-next/source/CellularManager
).

The debate is over this:

Prop 1:
RDK Network Manager -> RDK Cell Manager(everything to control/mng cell
modems) -> libQMI(FreeDesktop) -> Modem

Prop 2:
RDK Network Manager -> RDK Cell Manager(RDK to FOSS API adaptor) ->
ModemManager -> libQMI/MBIM(FreeDesktop) -> Modem


Getting ~100+ engineers/architects across dozens of company's spanning the
globe to agree on code is a challenging task which is why I write to ask for
advice.

I'd value input on shortfalls/under-estimations of rebuilding a robust cell
manager, ie. MM equivalent, from scratch. Here are some things I think are
under
estimated currently:

- Ability to handle different versions/variants in QMI, & MBIB
- Non-standard interfaces, such as GPS
- Advanced features such as VLANS, QoS, multi-routing/data multiplexing
- Overloadable feature architecture, like plugins, to handle custom
integrations
- Handling of async modem events/telemetry
- Dealing with AT commands (if required)
- Code that can scale to support more than a few target modem modules
- Sole burden of maintaining the above complex solution


The main concerns against using MM on the project are:
- Binary size (can remove plugin's and in future add more make flags to
remove
features[would be contribution])
- Performance,  (Allow list/udev tag's init modem quickly)
- Dbus, integration w/o it [distance future](Challenging but could be done
[would be contribution])
- Don't need voice or X feature (add more make flags to remove
features[would
be contribution])
- Upstream will slow down project or not accept MRs (Yocto + git-patch, send
proposal to ML before beginning work)


I think using MM has huge benefits over reinventing the wheel, what else
could
I add. I've tried to highlight:
- +10 years & 100+ contributors
- Proven on millions, at least, of deployments across many major Linux
distros
- Alread deployed in Tier 1 consumer devices - Chromebook / ChromeOS
- Awesome & responsive community of super smart folks
- Go fast alone, go far as a tribe


I really believe this could make such a big impact to the community so if
you
can spare advice on how I can help sell MM I'd love to hear it.

Thanks for coming to my Ted talk.


Cheers,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20220926/7478cf30/attachment.htm>