Instantiating rmnet devices for data ports on QRTR-based modems

[Aleksander Morgado]

Hey,

> > >         I seem we have done for "QMI based on QTRT" in libqmi.
> > >         For QUALCOMM's data services, there are lots of QMI library,
> > > and libqmi used a more simply solution. (in fact, if just send QMI,
> > > QTRT is also not a good idea)
> >
> > Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only way to
> > handle the communication in certain setups?
> [carl.yin] 1. QRTR codes is much complex than direct send QMI message via QMI channel like /dev/cdc-wdm0
>                 And it is not easy to find real hardware device for the QTRT node.
>                 No matter the hardware interface between AP and Qualcomm modem is USB/PCIE/SMD,
>                 (SMD is for QUALCOMM inter-AP, like MDM, APQ,MSM chipset.)
>                 There always have QMI channel can be used to send QMI message.
>                 If use these QMI channel, very few modifies is need apply to libqmi and MM

I cannot comment on this, probably @Eric Caruso has a better point of view.

> > This logic you're suggesting, except for step 5 I think, is what we already had in
> > mind more or less. I think we could have that done by ModemManager, and
> > connection managers like NetworkManager will get that working automatically,
> > but now I also fear that if we change the default QMI modem behavior w.r.t.
> > which is the connected network interface, we may be breaking user setups out
> > there that rely on fixed interface names (e.g. for iptables rules).
> >
> > >         rmnet_dataX is not a good name, there may be rment_usb0,
> > rment_mhi0 exist at the same time, so can named as rment_usb0_X.
> >
> > In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And if you
> > have 5 different modems, each of them instantiating muxed virtual interfaces,
> > they'll just get assigned sequential interface names, without any reference in the
> > interface name to which physical interface they're mapped to. I don't think the
> > name of the interface matters much at this point, as long as we can know which
> > virtual interface maps to which physical interface.
> >
> > E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs contents
> > pointing to the physical interface:
> > # ls -ltr /sys/class/net/qmimux0/lower_wwan0
> > lrwxrwxrwx    1 root     root             0 Oct 17 20:52
> > /sys/class/net/qmimux0/lower_wwan0 ->
> > ../../../pci0000:00/0000:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0
> >
> > And it adds a "upper_qmimux0" file in the physical interface sysfs pointing to the
> > virtual device:
> > # ls -ltr /sys/class/net/wwan0/upper_qmimux0
> > lrwxrwxrwx    1 root     root             0 Oct 17 20:53
> > /sys/class/net/wwan0/upper_qmimux0 ->
> > ../../../../../../../../virtual/net/qmimux0
> >
> > As long as we have this kind of relationship between the virtual and physical
> > interfaces, we're good to go, regardless of the actual naming of the interface.
> [carl.yin] developer can find the relationship of wwanX and qmimuxX.
>                 But for the end customers, maybe it is difficult, maybe he want to setup data call on PDN-x on modem y.
>                 It will be Very intuitive if we can make PDN-x to muxid-X to rmnet_modemY_X.

I truly don't have a strong opinion on that, kernel devs probably have
a better idea on what the naming should look like. Either way, it is
true that the current kernel implementation for the muxing in qmi_wwan
already relies on that naming mechanism, so not sure if that could be
changed right now without breaking the API.

-- 
Aleksander
https://aleksander.es