Hey Matthew, Let me add some more things to what Dylan already said.
> > 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. > That would be great! > > 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. > For the most part, QMI and MBIM (mostly led by Microsoft these days) are already the two main standards used by everyone, even if 3GPP keeps pushing the AT reference as the default one. I know there are some other protocols, like some binary proprietary protocol from MTK used in their SoCs, but if you ask me that is a step backwards overall (unless they publish the doc of the protocol). > 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 > There is one critical thing here, which is what role ModemManager plays in a connection stack. The role of MM is not to do a lot of custom control of what the device does; MM is just a somewhat "small" compatibility layer that exposes a single DBus API to manage any kind of modem behind. MM by itself won't do anything, it requires a user of its API (e.g. a connection manager on top of it) to connect or disconnect the modem, and so on. If you use MM, you don't need to know what protocol the modem is using; you don't need to know whether the QMI protocol in use is very new and things like NAS System Info can be used or if the QMI protocol in use is much older and only NAS Serving System is supported; you don't need to know whether plain MBIM 1.0 is supported or whether the device supports MBIM Extensions from Microsoft (be it v1, v2 or v3); you don't need to know whether GNSS management is done via AT commands + NMEA traces or via QMI LOC or via QMI PDS.... and so on. MM is an abstraction layer over all those things. There are cases where MM may not make sense, and I've found those myself over the past years when I was doing freelancing. The most clear example is if you need some quick connection manager that does very limited things, e.g. bring a very specific modem model up, run reconnections, and configure the IP settings itself. Simplicity like this has its drawbacks obviously, as you would be tied to a single module and upgrade path in the future may be complicated. > > 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. > Would you want to set up a video meeting with some of them if they need to clarify things? I can definitely help clarify things and I'm sure others like Dylan wouldn't mind to join as well. > 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 This is a key thing. Microsoft has extended MBIM with a ton of extensions, with different versions, and it gets very complex trying to support all. QMI may be a bit simpler, but that's just because the different version support has already been running in MM for many years so it's quite stable. > - Non-standard interfaces, such as GPS Yes, as soon as you want to do GNSS management, you would need to use per-manufacturer implementations. > - Advanced features such as VLANS, QoS, multi-routing/data multiplexing VLANs are really not managed by MM, they're one stage up in the stack. QoS is something I've been recently discussing with others, especially tied to e.g. 5G slicing. multi-routing and APN data multiplexing is already supported in QMI and MBIM; the only missing piece could be MTK SoCs. > - Overloadable feature architecture, like plugins, to handle custom > integrations MM has this already, yes. > - Handling of async modem events/telemetry Same. > - Dealing with AT commands (if required) The Modem.Command() API can be enabled on build time if needed. > - Code that can scale to support more than a few target modem modules MM currently supports >100 different modules, and those are only the ones I've tested myself lately. > - Sole burden of maintaining the above complex solution > I'm lucky to say that my current employer allows me to keep on maintaining the projects during my work time. Plus, more maintainers are always welcome! Dylan has been helping in reviewing merge requests lately, and I definitely wouldn't mind more helping hands around. > > 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]) Yes. Actually, something like 11 years ago there was already a patch from GIMP's maintainer Mitch to do that, but was not integrated because it was trying to disable too many things. But fully disabling features makes sense. One thing to keep in mind is that it's not only ifdefs to disable code; disabling a feature should also e.g. disable all AT URCs associated to that feature (e.g. AT+CRING regex match should still exist even if voice is disabled, and the regex should end up discarding the URC event silently if so). > - Performance, (Allow list/udev tag's init modem quickly) If modem layout is under control, udev tags can definitely be added to make it quicker to probe, there is no issue here. > - Dbus, integration w/o it [distance future](Challenging but could be done > [would be contribution]) This is not under scope at the moment. The whole MM codebase is very very very tied to DBus integration, and changing that would be a bit of a mess. We were able to get rid of the udev dependency for some systems like openwrt, but that still requires DBus. I know a lot of embedded systems that keep DBus only for ModemManager really, and they're not unhappy. > - Don't need voice or X feature (add more make flags to remove features[would > be contribution]) As said above. > - Upstream will slow down project or not accept MRs (Yocto + git-patch, send > proposal to ML before beginning work) > So this is really my fault :) I know I'm slow reviewing merge requests, but that is also sometimes due to how the merge requests are pushed. If the changes are pushed in a way that is easy for me to review (multiple commits with one logical change each, clear commit messages, and so on) then it's likely that I react to the MR in a better way. Also, multiple small MRs are much better to review than one single MR with a ton of changes. Anyway, I think I'm improving in all this lately, given that I can spend my worktime on reviewing stuff. Every MR that is flagged as Ready for Review will be reviewed shortly. As said earlier, more help would be welcome :) Regarding not accepting MRs, I've done that in the past mostly on technical grounds or because of the quality of the MR. If the submitter is able to provide technical reasoning or is able to rework the MRs to make them have better quality, I'd like to think that I'm reasonable and easy to convince. Sending the proposal to the mailing list or to gitlab (e.g. as a MR with the suggested changes in the API) before beginning the work is a key thing. > > 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 Plus, nowadays, Qualcomm and Intel themselves are involved in the development. > - Proven on millions, at least, of deployments across many major Linux > distros Yes. > - Alread deployed in Tier 1 consumer devices - Chromebook / ChromeOS Yes, and that support is not going away. > - Awesome & responsive community of super smart folks We don't bite! > - Go fast alone, go far as a tribe > True. > > 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. > Hope my comments help :) > Thanks for coming to my Ted talk. Hahah -- Aleksander
