<div dir="ltr"><span class="gmail-im" style="color:rgb(80,0,80)"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Would you want to set up a video meeting with some of them if they<br>need to clarify things? I can definitely help clarify things and I'm<br>sure others like Dylan wouldn't mind to join as well.</blockquote><div> </div></span><div>I got this approved. We have Bi-Weekly calls, the next is actually tomorrow at 8am PST / 5pm CET,</div><div>So if any bi-weekly dates on that timeframe works for you then let me know and I'll get it arranged from there.</div><span class="gmail-im" style="color:rgb(80,0,80)"><div><br></div></span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 29, 2022 at 2:35 PM matthew stanger <<a href="mailto:stangerm2@gmail.com">stangerm2@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Dylan,</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What is the problem here? Could you elaborate?</blockquote><div> </div><div>The desire is to have the fastest power on to cell connection. Folks point out<br>the probing times for modem detection as an example of unneeded/wasted<br>performance vs. a custom solution that already knows the modem/API/dev's that<br>it's talking to. This software supports retail consumers where time and<br>performance are very important. IMHO it's only AT command flows,<br>understandably, that can be slower. The RDK distro will only support modems<br>that support QMI/MBIM. No AT commands (maybe expect things like GPS, but<br>they'll have to be proxied).<br></div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No DBus, how will that go then for integration with other components?</blockquote><div> </div><div>I think this one is pretty out their myself, these systems use<br>hostapd/systemd/bluez already.. so trying to phase out dbus for performance<br>reasons seems like a tall order to me. A custom IPC/system-bus would be used in<br>it's place, called RBUS, it's open-sourced (<a href="https://github.com/rdkcmf/rbus" target="_blank">https://github.com/rdkcmf/rbus</a>). I<br>think this is a conceptual thing I can't image how that would work out.<br></div></div><div><br></div><div>Aleksander,</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I know there are some other protocols, like some binary proprietary<br>protocol from MTK used in their SoCs, but if you ask me that is a step<br>backwards overall (unless they publish the doc of the protocol).</blockquote><div> </div><div>We've already resolved this very thing. This is a perfect example of how we can<br>help the community with direct influence to silicon makers.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">you don't need to know whether the<br>QMI protocol in use is very new and things like NAS System Info can be<br>used or if the QMI protocol in use is much older and only NAS Serving<br>System is supported; you don't need to know whether plain MBIM 1.0 is<br>supported or whether the device supports MBIM Extensions from<br>Microsoft (be it v1, v2 or v3); you don't need to know whether GNSS<br>management is done via AT commands + NMEA traces or via QMI LOC or via<br>QMI PDS.... and so on. MM is an abstraction layer over all those<br>things.<br></blockquote><div> </div><div>These are very helpful points to me, TY! </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Simplicity like<br>this has its drawbacks obviously, as you would be tied to a single<br>module and upgrade path in the future may be complicated.<br></blockquote><div> </div><div>This is how the work body is thinking of this now, but for FWA to be successful<br>in this distro we'll need to allow MTK/QCOM module & direct modem support. I am<br>trying really hard to get folks to stop thinking about designing in a few QC<br>modems. We don't need to support every modem possible like desktop tries to do<br>but we do need to have the flexibility to scale generation after generation.<br>I'm trying to focus everyone on supporting the protocols as standards.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Would you want to set up a video meeting with some of them if they<br>need to clarify things? I can definitely help clarify things and I'm<br>sure others like Dylan wouldn't mind to join as well.</blockquote><div> </div><div>It'd be amazing if you/Dylan could drop in for 30 mins, and I think it'd speak<br>volumes to the projects quality (I wanted to hire you for these things :) FWIW<br>before you got snatched up). I'll need to get permission from the working group<br>and get back to you. Meetings are Bi-weekly, I don't think it'd be an issue.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is a key thing. Microsoft has extended MBIM with a ton of<br>extensions, with different versions, and it gets very complex trying<br>to support all. </blockquote><div> </div><div>Very good to know. MBIM is the target for any chipset that doesn't support</div><div>QMI and we're taking a hard line on that. This is the way.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">QoS is something I've been recently discussing with others, especially<br>tied to e.g. 5G slicing.<br>multi-routing and APN data multiplexing is already supported in QMI<br>and MBIM; the only missing piece could be MTK SoCs.</blockquote><div> </div><div>Any opinions on support for ENDC/SA, carrier aggregation, eSIM or low level features<br>like this. Usually this is at the modem FW level but there are times when this<br>stuff needs to be controlled (on/off really). IMO it makes sense to expose<br>these things through MM to me, but I'm not sure if the project has dealt with<br>features at that level? <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">MM currently supports >100 different modules, and those are only the<br>ones I've tested myself lately.</blockquote><div> </div><div>Another exciting opportunity is the testing hardware pipelines this distro<br>brings. Plus we'd be testing the whole stack w/ MM/lib's at the carrier/PTCRB<br>level in NA/EU at min. I wonder if we could help drive to a regulation standard<br>one day (big stretch), kind of like CRDA for Wifi. The stuff going on with<br>SXD55 and FCC unlocks looks a bit painful for the community?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yes. Actually, something like 11 years ago there was already a patch<br>from GIMP's maintainer Mitch to do that, but was not integrated<br>because it was trying to disable too many things. But fully disabling<br>features makes sense. One thing to keep in mind is that it's not only<br>ifdefs to disable code; disabling a feature should also e.g. disable<br>all AT URCs associated to that feature (e.g. AT+CRING regex match<br>should still exist even if voice is disabled, and the regex should end<br>up discarding the URC event silently if so).</blockquote><div> </div><div> Not an issue, we have many OEM engineering teams available. As long as I can<br>get them clear direction, like you stated here we can get that kind of work<br>done the way it'd be accepted by you. All of these tweaks would be a phase 2<br>thing anyways, first I need to get the win to lock this architecture in. Then<br>we can figure out what tuning makes since, but I did want to shed some light on<br>some tweaks that could happen.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is not under scope at the moment. The whole MM codebase is very<br>very very tied to DBus integration, and changing that would be a bit<br>of a mess. We were able to get rid of the udev dependency for some<br>systems like openwrt, but that still requires DBus. I know a lot of<br>embedded systems that keep DBus only for ModemManager really, and<br>they're not unhappy.</blockquote><div> </div><div>As I stated to Dylan above, this a head scratcher to me too but I'm just trying<br>to get feedback and address everyone. I can't imagine how this would ever work<br>out, as I mentioned above the distro already uses many dbus Linux programs so<br>all that would have to be undone somehow... It's a very long term goal(years)<br>for them but I think it's more of a tech debt stance. I understand this isn't<br>something this community would want, no hard feelings here. I don't want it<br>either but I also don't want it to derail getting MM into the stack, so I'm<br>trying to address the concern carefully.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So this is really my fault :) I know I'm slow reviewing merge<br>requests, but that is also sometimes due to how the merge requests are<br>pushed. If the changes are pushed in a way that is easy for me to<br>review (multiple commits with one logical change each, clear commit<br>messages, and so on) then it's likely that I react to the MR in a<br>better way. Also, multiple small MRs are much better to review than<br>one single MR with a ton of changes. Anyway, I think I'm improving in<br>all this lately, given that I can spend my worktime on reviewing<br>stuff. Every MR that is flagged as Ready for Review will be reviewed<br>shortly. As said earlier, more help would be welcome :) Regarding not<br>accepting MRs, I've done that in the past mostly on technical grounds<br>or because of the quality of the MR. If the submitter is able to<br>provide technical reasoning or is able to rework the MRs to make them<br>have better quality, I'd like to think that I'm reasonable and easy to<br>convince. Sending the proposal to the mailing list or to gitlab (e.g.<br>as a MR with the suggested changes in the API) before beginning the<br>work is a key thing.</blockquote><div> </div><div>What? No, you are very quick IMO, lol. Case in point look at those PPA turn<br>around times in Ubuntu. I promise no code with synchronous sleeps will enter<br>the ML :) through us.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hope my comments help :)</blockquote><div> </div><div>Yes, very much. Thanks for taking the time to respond to all this.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 28, 2022 at 1:03 AM Aleksander Morgado <<a href="mailto:aleksandermj@chromium.org" target="_blank">aleksandermj@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Matthew,<br>
<br>
Let me add some more things to what Dylan already said.<br>
<br>
><br>
> TLDR: I'm seeking input to help champion MM as a core cell management component<br>
> to a large firmware collaborations body. If successful, IMHO, it'd have huge<br>
> benefits to WWAN/Linux wireless & MM as it'd bring in a lot of official<br>
> support, more WWAN standardization, and muscle to the community.<br>
><br>
<br>
That would be great!<br>
<br>
><br>
> Here's the situation.<br>
><br>
> We're working with the RDK community to add Fixed Wireless Access support to<br>
> the project. If you've never heard of RDK before it's basically like Android<br>
> for STBs & modems (<a href="http://rdkcentral.com/rdk-profiles/)%5B+80" rel="noreferrer" target="_blank">rdkcentral.com/rdk-profiles/)[+80</a> Million deployments].<br>
> Chances are if you have a modem/STB in the US or EU it runs this software. So<br>
> why does this matter to MM?<br>
><br>
> Getting MM in this distro would bring in a form of direct support to<br>
> libQMI/libMBIM from the two silicon makers and a small army of developers. It<br>
> would help reinforce QMI/MBIM as standards across the WWAN industry and<br>
> enhance feature/quality for those libraries and MM.<br>
><br>
<br>
For the most part, QMI and MBIM (mostly led by Microsoft these days)<br>
are already the two main standards used by everyone, even if 3GPP<br>
keeps pushing the AT reference as the default one.<br>
I know there are some other protocols, like some binary proprietary<br>
protocol from MTK used in their SoCs, but if you ask me that is a step<br>
backwards overall (unless they publish the doc of the protocol).<br>
<br>
> Currently there is debate on the best solution/architecture for RDK for cell<br>
> support (data-only modems). While I champion for the full MM + libQMI/MBIM<br>
> stack many want to only use libQMI/MBIM and propose a custom but technically<br>
> FOSS RDK cell manager<br>
> (<a href="https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/RdkCellularManager/+/refs/heads/rdk-next/source/CellularManager" rel="noreferrer" target="_blank">https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/RdkCellularManager/+/refs/heads/rdk-next/source/CellularManager</a>).<br>
><br>
> The debate is over this:<br>
><br>
> Prop 1:<br>
> RDK Network Manager -> RDK Cell Manager(everything to control/mng cell modems) -> libQMI(FreeDesktop) -> Modem<br>
><br>
> Prop 2:<br>
> RDK Network Manager -> RDK Cell Manager(RDK to FOSS API adaptor) -> ModemManager -> libQMI/MBIM(FreeDesktop) -> Modem<br>
><br>
<br>
There is one critical thing here, which is what role ModemManager<br>
plays in a connection stack. The role of MM is not to do a lot of<br>
custom control of what the device does; MM is just a somewhat "small"<br>
compatibility layer that exposes a single DBus API to manage any kind<br>
of modem behind. MM by itself won't do anything, it requires a user of<br>
its API (e.g. a connection manager on top of it) to connect or<br>
disconnect the modem, and so on. If you use MM, you don't need to know<br>
what protocol the modem is using; you don't need to know whether the<br>
QMI protocol in use is very new and things like NAS System Info can be<br>
used or if the QMI protocol in use is much older and only NAS Serving<br>
System is supported; you don't need to know whether plain MBIM 1.0 is<br>
supported or whether the device supports MBIM Extensions from<br>
Microsoft (be it v1, v2 or v3); you don't need to know whether GNSS<br>
management is done via AT commands + NMEA traces or via QMI LOC or via<br>
QMI PDS.... and so on. MM is an abstraction layer over all those<br>
things.<br>
<br>
There are cases where MM may not make sense, and I've found those<br>
myself over the past years when I was doing freelancing. The most<br>
clear example is if you need some quick connection manager that does<br>
very limited things, e.g. bring a very specific modem model up, run<br>
reconnections, and configure the IP settings itself. Simplicity like<br>
this has its drawbacks obviously, as you would be tied to a single<br>
module and upgrade path in the future may be complicated.<br>
<br>
><br>
> Getting ~100+ engineers/architects across dozens of company's spanning the<br>
> globe to agree on code is a challenging task which is why I write to ask for<br>
> advice.<br>
><br>
<br>
Would you want to set up a video meeting with some of them if they<br>
need to clarify things? I can definitely help clarify things and I'm<br>
sure others like Dylan wouldn't mind to join as well.<br>
<br>
> I'd value input on shortfalls/under-estimations of rebuilding a robust cell<br>
> manager, ie. MM equivalent, from scratch. Here are some things I think are under<br>
> estimated currently:<br>
><br>
> - Ability to handle different versions/variants in QMI, & MBIB<br>
<br>
This is a key thing. Microsoft has extended MBIM with a ton of<br>
extensions, with different versions, and it gets very complex trying<br>
to support all. QMI may be a bit simpler, but that's just because the<br>
different version support has already been running in MM for many<br>
years so it's quite stable.<br>
<br>
> - Non-standard interfaces, such as GPS<br>
<br>
Yes, as soon as you want to do GNSS management, you would need to use<br>
per-manufacturer implementations.<br>
<br>
> - Advanced features such as VLANS, QoS, multi-routing/data multiplexing<br>
<br>
VLANs are really not managed by MM, they're one stage up in the stack.<br>
QoS is something I've been recently discussing with others, especially<br>
tied to e.g. 5G slicing.<br>
multi-routing and APN data multiplexing is already supported in QMI<br>
and MBIM; the only missing piece could be MTK SoCs.<br>
<br>
> - Overloadable feature architecture, like plugins, to handle custom<br>
> integrations<br>
<br>
MM has this already, yes.<br>
<br>
> - Handling of async modem events/telemetry<br>
<br>
Same.<br>
<br>
> - Dealing with AT commands (if required)<br>
<br>
The Modem.Command() API can be enabled on build time if needed.<br>
<br>
> - Code that can scale to support more than a few target modem modules<br>
<br>
MM currently supports >100 different modules, and those are only the<br>
ones I've tested myself lately.<br>
<br>
> - Sole burden of maintaining the above complex solution<br>
><br>
<br>
I'm lucky to say that my current employer allows me to keep on<br>
maintaining the projects during my work time. Plus, more maintainers<br>
are always welcome! Dylan has been helping in reviewing merge requests<br>
lately, and I definitely wouldn't mind more helping hands around.<br>
<br>
><br>
> The main concerns against using MM on the project are:<br>
> - Binary size (can remove plugin's and in future add more make flags to remove<br>
> features[would be contribution])<br>
<br>
Yes. Actually, something like 11 years ago there was already a patch<br>
from GIMP's maintainer Mitch to do that, but was not integrated<br>
because it was trying to disable too many things. But fully disabling<br>
features makes sense. One thing to keep in mind is that it's not only<br>
ifdefs to disable code; disabling a feature should also e.g. disable<br>
all AT URCs associated to that feature (e.g. AT+CRING regex match<br>
should still exist even if voice is disabled, and the regex should end<br>
up discarding the URC event silently if so).<br>
<br>
> - Performance,  (Allow list/udev tag's init modem quickly)<br>
<br>
If modem layout is under control, udev tags can definitely be added to<br>
make it quicker to probe, there is no issue here.<br>
<br>
> - Dbus, integration w/o it [distance future](Challenging but could be done<br>
> [would be contribution])<br>
<br>
This is not under scope at the moment. The whole MM codebase is very<br>
very very tied to DBus integration, and changing that would be a bit<br>
of a mess. We were able to get rid of the udev dependency for some<br>
systems like openwrt, but that still requires DBus. I know a lot of<br>
embedded systems that keep DBus only for ModemManager really, and<br>
they're not unhappy.<br>
<br>
> - Don't need voice or X feature (add more make flags to remove features[would<br>
> be contribution])<br>
<br>
As said above.<br>
<br>
> - Upstream will slow down project or not accept MRs (Yocto + git-patch, send<br>
> proposal to ML before beginning work)<br>
><br>
<br>
So this is really my fault :) I know I'm slow reviewing merge<br>
requests, but that is also sometimes due to how the merge requests are<br>
pushed. If the changes are pushed in a way that is easy for me to<br>
review (multiple commits with one logical change each, clear commit<br>
messages, and so on) then it's likely that I react to the MR in a<br>
better way. Also, multiple small MRs are much better to review than<br>
one single MR with a ton of changes. Anyway, I think I'm improving in<br>
all this lately, given that I can spend my worktime on reviewing<br>
stuff. Every MR that is flagged as Ready for Review will be reviewed<br>
shortly. As said earlier, more help would be welcome :) Regarding not<br>
accepting MRs, I've done that in the past mostly on technical grounds<br>
or because of the quality of the MR. If the submitter is able to<br>
provide technical reasoning or is able to rework the MRs to make them<br>
have better quality, I'd like to think that I'm reasonable and easy to<br>
convince. Sending the proposal to the mailing list or to gitlab (e.g.<br>
as a MR with the suggested changes in the API) before beginning the<br>
work is a key thing.<br>
<br>
><br>
> I think using MM has huge benefits over reinventing the wheel, what else could<br>
> I add. I've tried to highlight:<br>
> - +10 years & 100+ contributors<br>
<br>
Plus, nowadays, Qualcomm and Intel themselves are involved in the development.<br>
<br>
> - Proven on millions, at least, of deployments across many major Linux<br>
> distros<br>
<br>
Yes.<br>
<br>
> - Alread deployed in Tier 1 consumer devices - Chromebook / ChromeOS<br>
<br>
Yes, and that support is not going away.<br>
<br>
> - Awesome & responsive community of super smart folks<br>
<br>
We don't bite!<br>
<br>
> - Go fast alone, go far as a tribe<br>
><br>
<br>
True.<br>
<br>
><br>
> I really believe this could make such a big impact to the community so if you<br>
> can spare advice on how I can help sell MM I'd love to hear it.<br>
><br>
<br>
Hope my comments help :)<br>
<br>
> Thanks for coming to my Ted talk.<br>
<br>
Hahah<br>
<br>
-- <br>
Aleksander<br>
</blockquote></div></div>
</blockquote></div>