Instantiating rmnet devices for data ports on QRTR-based modems

[Eric Caruso]

Hey all,

As part of the QRTR integration into MM we're trying to figure out
whose responsibility it is to make rmnet_data net interfaces for a
QRTR/IPA-based modem. I had started an MR[1] that gave this
responsibility to libqmi, but it's not clear this is the right place
for this to go.

If we leave it in libqmi, then ModemManager has to do very little
extra setup: it can just grab the mux ID from the QmiDevice and push
it to the modem via Bind Mux Data Port in the connect step[2]. The
QmiDevice can also cache the interface name it selected when creating
the net port to return from reload_wwan_iface.

However, delegating it to MM also works. I think that the conceptual
design is cleaner here as interacting with netlink to create
interfaces isn't really something that makes a ton of sense to leave
in libqmi. It does mean that MM will have to instantiate net ports and
then assign the mux ID to the QmiDevice, and then set it again in the
Bind Mux Data Port message, which leaves room for those potentially
getting out of sync. It also means that under more generalized
operation (where we don't necessarily follow the rmnet_dataX = mux ID
X+1 convention[3]) we'd still need to use netlink from libqmi to fetch
all of the rmnet interfaces and inspect their mux ID properties to
find a match when performing reload_wwan_iface. (On an abstract level,
this seems as valid a use for netlink for libqmi as it is valid for
libqmi to crawl sysfs for net interface details. But it does increase
the total complexity of the code, since MM and libqmi are essentially
exchanging information through the kernel.)

One thing that we'll have to consider in the future, though not right
now, is how each design works with multiple PDN operation -- I think
the design implied by the libqmi MR[1] makes this difficult, but
libqmi also seems to make the assumption that we only associate each
device with one net port anyway, so we may have to unwind that
assumption no matter what. The design where MM instantiates net ports
might not run into this issue in so many places.

[1] https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/135
[2] https://chromium.googlesource.com/chromiumos/third_party/modemmanager-next/+/dbee3f23a9c27d8bf3f5e634dabb41ef856867f8
[3] This convention was alluded to by QC, but there's no magic in it
and a user could easily break this with two invocations of the "ip"
command, which might cause some tricky bugs. So I don't know that we
should try to keep the convention, and instead just find any open
rmnet_dataX and mux ID and link those together.

Thanks,
-Eric