<div dir="ltr"><div>Hey,</div><div><br></div><div>We've decided to move the rmnet configuration to libqmi. It seems to be a better place because there is already a class for QRTR control socket.</div><div><a href="https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102">https://gitlab.freedesktop.</a><a href="https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102">org/mkm/libqmi/-/commit/</a><a href="https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102">3e063884efd6cc217e91be4601ee3b</a></div><div> </div><div>This patch adds a new class for QRTR data port. During initialization it opens an INET socket to bring up the rmnet_ipa device and uses the rmnetctl library to create a virtual network device (rmnet_data0). This new device will be used in ModemManager.</div><div>Can you please have a look and let me know what you think?<br></div><div><br></div><div>Thanks,</div><div>Michal<br></div><div><br></div><div><a href="https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102" target="_blank"></a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 24 wrz 2020 o 11:33 Aleksander Morgado <<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>> napisał(a):<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!<br>
<br>
><br>
> I'm working on the setup of a rmnet device for QRTR node and would like to create a new file mm-kernel-device-rmnet.c in src/kerneldevice. Support for the QRTR kernel device subclass will be in src/kerneldevice/mm-kernel-device-qrtr.c.<br>
> Setup function would be called from mm-base-manager.c when new QRTR node is detected and just before calling mm_kernel_device_qrtr_new.<br>
> Will it be a good place for the file?<br>
><br>
<br>
How is the rmnet device exposed in the kernel? Is it exposed as a<br>
plain network interface?<br>
What is the rmnetctl library interfacing with? Is it doing operations<br>
on the network interface itself?<br>
<br>
I ask these because for the purpose of a MMKernelDevice, it may be<br>
enough to use the standard object to detect the interface, which is<br>
the main purpose of the MMKernelDevice setup.<br>
<br>
In the case of the QRTR backend, it makes sense a MMKernelDeviceQrtr<br>
because the "device" is a "node" in the QRTR bus, so it's really a new<br>
kind of "device" exposed by the kernel. Once the kernel object is<br>
available, operations with the QRTR protocol should be done through a<br>
new MMPortQrtr object. In ModemManager, "ports" are the ones that<br>
provide control capabilities, while "kernel devices" are just the ones<br>
mapping the ports to interfaces in the system. If you need to perform<br>
operations on the rmnet interface, you'll need a MMPort subclass, e.g.<br>
a new MMPortRmnet, but if the rmnet has a standard network interface<br>
exposed, you may not need the custom MMKernelDeviceRmnet.<br>
<br>
> Location of wip changes:<br>
> <a href="https://gitlab.freedesktop.org/mkm/ModemManager/-/commits/porting-netmngr-into-modemmanager" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mkm/ModemManager/-/commits/porting-netmngr-into-modemmanager</a><br>
><br>
<br>
Gave it a quick look, and I believe you were trying to add new control<br>
APIs in the MMKernelDevice itself, that is not right, the control APIs<br>
should go into the MMPortRmnet, the kernel device is just the<br>
representation of the device exposed by the kernel inside<br>
ModemManager, the port objects are the ones that perform operations.<br>
Oh, and port objects that allow control operations should also be<br>
"probed" before assuming they can be used by the modem. That is some<br>
other thing to think of.<br>
<br>
> Another question: how can I test if rmnetctl library is available when pkg-config cannot find it in search path?<br>
> I tried to use PKG_CHECK_MODULES like for QMI but librmnetctl doesn't have a .pc file:<br>
>         PKG_CHECK_MODULES(QRTR, rmnetctl, [have_rmnet=yes],[have_rmnet=no])<br>
><br>
<br>
If the rmnetctl library doesn't provide a pkgconfig setup file, you<br>
should use the standard autoconf macros to check for both the library<br>
header (AC_CHECK_HEADER) and the library link support (AC_CHECK_LIB).<br>
<br>
I'm going to suggest doing one more thing, if possible. The rmnetctl<br>
library provides a simple sync API to operate over a rmnetctl_hndl_t.<br>
Could you make sure all code that uses the rmnetctl library fits into<br>
a single GObject? E.g. the MMPortRmnet object that I referred to<br>
previously should handle all the code using that library. This is<br>
because we'll also need to #ifdef the whole QRTR and rmnet support so<br>
that it can easily be disabled or enabled during configure.<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div>