Location of rmnet setup

[Michał Mazur]

Hey,

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.
https://gitlab.freedesktop.
<https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102>
org/mkm/libqmi/-/commit/
<https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102>
3e063884efd6cc217e91be4601ee3b
<https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102>
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.
Can you please have a look and let me know what you think?

Thanks,
Michal

<https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b587bda5102>

czw., 24 wrz 2020 o 11:33 Aleksander Morgado <aleksander at aleksander.es>
napisał(a):

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20201002/1ef6f73d/attachment.htm>