Location of rmnet setup

[Aleksander Morgado]

Hey!

>
> 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.
> 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.
> Will it be a good place for the file?
>

How is the rmnet device exposed in the kernel? Is it exposed as a
plain network interface?
What is the rmnetctl library interfacing with? Is it doing operations
on the network interface itself?

I ask these because for the purpose of a MMKernelDevice, it may be
enough to use the standard object to detect the interface, which is
the main purpose of the MMKernelDevice setup.

In the case of the QRTR backend, it makes sense a MMKernelDeviceQrtr
because the "device" is a "node" in the QRTR bus, so it's really a new
kind of "device" exposed by the kernel. Once the kernel object is
available, operations with the QRTR protocol should be done through a
new MMPortQrtr object. In ModemManager, "ports" are the ones that
provide control capabilities, while "kernel devices" are just the ones
mapping the ports to interfaces in the system. If you need to perform
operations on the rmnet interface, you'll need a MMPort subclass, e.g.
a new MMPortRmnet, but if the rmnet has a standard network interface
exposed, you may not need the custom MMKernelDeviceRmnet.

> Location of wip changes:
> https://gitlab.freedesktop.org/mkm/ModemManager/-/commits/porting-netmngr-into-modemmanager
>

Gave it a quick look, and I believe you were trying to add new control
APIs in the MMKernelDevice itself, that is not right, the control APIs
should go into the MMPortRmnet, the kernel device is just the
representation of the device exposed by the kernel inside
ModemManager, the port objects are the ones that perform operations.
Oh, and port objects that allow control operations should also be
"probed" before assuming they can be used by the modem. That is some
other thing to think of.

> Another question: how can I test if rmnetctl library is available when pkg-config cannot find it in search path?
> I tried to use PKG_CHECK_MODULES like for QMI but librmnetctl doesn't have a .pc file:
>         PKG_CHECK_MODULES(QRTR, rmnetctl, [have_rmnet=yes],[have_rmnet=no])
>

If the rmnetctl library doesn't provide a pkgconfig setup file, you
should use the standard autoconf macros to check for both the library
header (AC_CHECK_HEADER) and the library link support (AC_CHECK_LIB).

I'm going to suggest doing one more thing, if possible. The rmnetctl
library provides a simple sync API to operate over a rmnetctl_hndl_t.
Could you make sure all code that uses the rmnetctl library fits into
a single GObject? E.g. the MMPortRmnet object that I referred to
previously should handle all the code using that library. This is
because we'll also need to #ifdef the whole QRTR and rmnet support so
that it can easily be disabled or enabled during configure.

-- 
Aleksander
https://aleksander.es