Re: Location of rmnet setup

[Michał Mazur]

Hi,

It seems we are using a part from Qualcomm's dataservices repository:
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/dataservices/
Few projects took a snapshot of a certain branch or tag and maybe adjusted
the library so in my opinion its better to keep it separate and use common
API.

Thanks,
Michal


pt., 9 paź 2020 o 10:41 Aleksander Morgado 
napisał(a):

> Hey,
>
> >
> > I don't know location of the official librmnetctl repo. We are using
> snapshot from branch LC.UM.1.0 of
> > https://source.codeaurora.org/quic/lc/chromiumos/third_party/librmnetctl
> >
>
> If we're looking at using just some netlink socket based operations,
> and if there is no "official" single librmnetctl library released
> anywhere (didn't check myself) we could also import the operations to
> MM itself?
>
> --
> Aleksander
> https://aleksander.es
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Location of rmnet setup

[Aleksander Morgado]

Hey,

>
> I don't know location of the official librmnetctl repo. We are using snapshot 
> from branch LC.UM.1.0 of
> https://source.codeaurora.org/quic/lc/chromiumos/third_party/librmnetctl
>

If we're looking at using just some netlink socket based operations,
and if there is no "official" single librmnetctl library released
anywhere (didn't check myself) we could also import the operations to
MM itself?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Location of rmnet setup

[Aleksander Morgado]

Hey Michał,

>
> Thank you for the reply. As you suggested I created MMPortRmnet to handle 
> data port setup:
> https://gitlab.freedesktop.org/mkm/ModemManager/-/commit/b25310666e41a19150fe2b18ff3b7cce73f9129a
> It includes all the code that uses the rmnet library to configure devices but 
> it is not probed yet.
>

Nice thing! Please also check the discussion with Stephan (working on
RPMSG+BAM-DMUX) here
https://gitlab.freedesktop.org/andrewlassalle/ModemManager/-/merge_requests/5#note_646032


--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Location of rmnet setup

[Michał Mazur]

Hi Daniele,

I don't know location of the official librmnetctl repo. We are using
snapshot from branch LC.UM.1.0 of
https://source.codeaurora.org/quic/lc/chromiumos/third_party/librmnetctl

Regards,
Michal

pt., 9 paź 2020 o 08:02 Daniele Palmas  napisał(a):

> Hi Michal,
>
> Il ven 9 ott 2020, 04:05 Michał Mazur  ha scritto:
>
>> Hi Aleksander,
>>
>> Thank you for the reply. As you suggested I created MMPortRmnet to handle
>> data port setup:
>>
>> https://gitlab.freedesktop.org/mkm/ModemManager/-/commit/b25310666e41a19150fe2b18ff3b7cce73f9129a
>> It includes all the code that uses the rmnet library to configure devices
>> but it is not probed yet.
>>
>
> Can you please post a link for the official librmnetctl code repository?
>
> I can find many, but I'm not sure of the correct one.
>
> Thanks,
> Daniele
>
>
>> Regards,
>> Michal
>>
>>
>> sob., 3 paź 2020 o 14:34 Aleksander Morgado 
>> napisał(a):
>>
>>> Hey Michał!
>>>
>>> >
>>> > 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.
>>>
>>> I would suggest discussing in the public mailing list or in gitlab
>>> issues this kind of thing, so that everyone can participate in the
>>> discussion.
>>>
>>> >
>>> >
>>> https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b
>>> > 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.
>>>
>>> How is it that the "QRTR data port" does nothing with the QRTR
>>> protocol? Yes, this rmnet data port is the one that would be used for
>>> data while QRTR is used for control, but I don't think libqrtr would
>>> be the place to add this. From an outsider perspective, you could say
>>> you need libqmi+libqrtr for control, and rmnetctl to bring up the data
>>> network interface, but I wouldn't add this new object in libqrtr, as
>>> it really has nothing to do with the QRTR protocol itself.
>>>
>>> If you ask me, ModemManager is a better place for this, e.g. a let's
>>> say a MMPortRmnet object which would map the virtual network interface
>>> created with rmnetctl. Oh wait, I did already suggest something like
>>> this in a previous email that was never replied...
>>>
>>> --
>>> Aleksander
>>> https://aleksander.es
>>> ___
>>> ModemManager-devel mailing list
>>> ModemManager-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>>>
>> ___
>> ModemManager-devel mailing list
>> ModemManager-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>>
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Location of rmnet setup

[Daniele Palmas]

Hi Michal,

Il ven 9 ott 2020, 04:05 Michał Mazur  ha scritto:

> Hi Aleksander,
>
> Thank you for the reply. As you suggested I created MMPortRmnet to handle
> data port setup:
>
> https://gitlab.freedesktop.org/mkm/ModemManager/-/commit/b25310666e41a19150fe2b18ff3b7cce73f9129a
> It includes all the code that uses the rmnet library to configure devices
> but it is not probed yet.
>

Can you please post a link for the official librmnetctl code repository?

I can find many, but I'm not sure of the correct one.

Thanks,
Daniele


> Regards,
> Michal
>
>
> sob., 3 paź 2020 o 14:34 Aleksander Morgado 
> napisał(a):
>
>> Hey Michał!
>>
>> >
>> > 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.
>>
>> I would suggest discussing in the public mailing list or in gitlab
>> issues this kind of thing, so that everyone can participate in the
>> discussion.
>>
>> >
>> >
>> https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b
>> > 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.
>>
>> How is it that the "QRTR data port" does nothing with the QRTR
>> protocol? Yes, this rmnet data port is the one that would be used for
>> data while QRTR is used for control, but I don't think libqrtr would
>> be the place to add this. From an outsider perspective, you could say
>> you need libqmi+libqrtr for control, and rmnetctl to bring up the data
>> network interface, but I wouldn't add this new object in libqrtr, as
>> it really has nothing to do with the QRTR protocol itself.
>>
>> If you ask me, ModemManager is a better place for this, e.g. a let's
>> say a MMPortRmnet object which would map the virtual network interface
>> created with rmnetctl. Oh wait, I did already suggest something like
>> this in a previous email that was never replied...
>>
>> --
>> Aleksander
>> https://aleksander.es
>> ___
>> ModemManager-devel mailing list
>> ModemManager-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>>
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Location of rmnet setup

[Michał Mazur]

Hi Aleksander,

Thank you for the reply. As you suggested I created MMPortRmnet to handle
data port setup:
https://gitlab.freedesktop.org/mkm/ModemManager/-/commit/b25310666e41a19150fe2b18ff3b7cce73f9129a
It includes all the code that uses the rmnet library to configure devices
but it is not probed yet.

Regards,
Michal


sob., 3 paź 2020 o 14:34 Aleksander Morgado 
napisał(a):

> Hey Michał!
>
> >
> > 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.
>
> I would suggest discussing in the public mailing list or in gitlab
> issues this kind of thing, so that everyone can participate in the
> discussion.
>
> >
> >
> https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b
> > 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.
>
> How is it that the "QRTR data port" does nothing with the QRTR
> protocol? Yes, this rmnet data port is the one that would be used for
> data while QRTR is used for control, but I don't think libqrtr would
> be the place to add this. From an outsider perspective, you could say
> you need libqmi+libqrtr for control, and rmnetctl to bring up the data
> network interface, but I wouldn't add this new object in libqrtr, as
> it really has nothing to do with the QRTR protocol itself.
>
> If you ask me, ModemManager is a better place for this, e.g. a let's
> say a MMPortRmnet object which would map the virtual network interface
> created with rmnetctl. Oh wait, I did already suggest something like
> this in a previous email that was never replied...
>
> --
> Aleksander
> https://aleksander.es
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Location of rmnet setup

[Aleksander Morgado]

Hey Michał!

>
> 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.

I would suggest discussing in the public mailing list or in gitlab
issues this kind of thing, so that everyone can participate in the
discussion.

>
> https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b
> 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.

How is it that the "QRTR data port" does nothing with the QRTR
protocol? Yes, this rmnet data port is the one that would be used for
data while QRTR is used for control, but I don't think libqrtr would
be the place to add this. From an outsider perspective, you could say
you need libqmi+libqrtr for control, and rmnetctl to bring up the data
network interface, but I wouldn't add this new object in libqrtr, as
it really has nothing to do with the QRTR protocol itself.

If you ask me, ModemManager is a better place for this, e.g. a let's
say a MMPortRmnet object which would map the virtual network interface
created with rmnetctl. Oh wait, I did already suggest something like
this in a previous email that was never replied...

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: 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.

org/mkm/libqmi/-/commit/

3e063884efd6cc217e91be4601ee3b

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



czw., 24 wrz 2020 o 11:33 Aleksander Morgado 
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
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

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