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
