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

[Dylan Van Assche]

Hi,

I contributed already a few times to ModemManager (small and big
contributions).

On Mon, 2022-09-26 at 16:53 -0700, matthew stanger wrote:
> 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.
> 
> 

IMO, MM is *the* daemon for this stuff because of the community, wide
support, integration and many more. MM is integrated already in a wide
range of FOSS tools and environments. It is currently the daemon that
handles all the modem stuff on all Linux Mobile phones.

> 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/opensour
> ce/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
> 

Even if MM is not used, using libqmi/libmbim makes so much sense.
Dealing with this stuff again is just fragmenting the ecosystem which
helps nobody. They only contain the stuff to execute a certain request
so no actually handling of the 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

MM can do that, the plugins and quirks with UDEV tags works nicely
here.

> - Non-standard interfaces, such as GPS

MM has support for GPS, NTP time, etc.

> - Advanced features such as VLANS, QoS, multi-routing/data
> multiplexing

No idea about this

> - Overloadable feature architecture, like plugins, to handle custom
> integrations

Plugins are IMO the way to handle this stuff, modems are similar but
always a little bit different.

> - Handling of async modem events/telemetry

MM is fully async with GTasks, so covered :)

> - Dealing with AT commands (if required)

MM handles that pretty well, custom AT commands are done in plugins.

> - Code that can scale to support more than a few target modem modules

MM is exactly that...

> - Sole burden of maintaining the above complex solution

That's why a community is needed, maintaining a few modems might be
doable with a lot of engineers, but not on the scale that MM is
maintaining supported modems.

> 
> 
> 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

fwupd has a similar plugin infrastructure, MM can probably do the same
as them which allows to build plugins or not using build flags.
On Alpine Linux we even split up all fwupd plugins in separate packages
to reduce the binary size.

> features[would be contribution])
> - Performance,  (Allow list/udev tag's init modem quickly)

What is the problem here? Could you elaborate?

> - Dbus, integration w/o it [distance future](Challenging but could be
> done

No DBus, how will that go then for integration with other components?

> [would be contribution])
> - Don't need voice or X feature (add more make flags to remove
> features[would
> be contribution])

I guess interfaces such as Voice, Time, Location, etc. could be
disabled when building with flags?

> - Upstream will slow down project or not accept MRs (Yocto + git-
> patch, send
> proposal to ML before beginning work)
> 

Upstream is really responsive and is just awesome.
For big contributions, creating an issue in the repos or sending an
email to the ML is useful though, just to avoid doing the same thing
twice or apply changes which are controversial or are just affecting a
lot of devices.

> 
> 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

Totally agree here!
MM is developed actively, which is not the same with other modem
daemons.

> 
> 
> 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

Cheers,
Dylan