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 _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
