Use a specific device ?

[Aleksander Morgado]

Hey,

>>>> I you follow the previous paragraph, you will understand that it's
>>>> clearly the job of ModemManager. This just plain logic as this is the
>>>> only entity in the chain that receive the udev event about the modem.
>>>
>>> I don't necessarily think it is ModemManager's job.  Since what you want
>>> in the end is to tie a specific NM connection to a specific modem (based
>>> on type, slot #, whatever), it's the job of NetworkManager to figure
>>> that out for you.  ModemManager can certainly help if we can figure out
>>> a clean generic way to do that.
>>
>> FWIW, I agree here.
>>
>> Once you have more than one modem/SIM/operator/whatever, then you cannot
>> automatically do-the-right-thing-for-everyone.  You can select
>> reasonable defaults of course, but the final modem selection policy
>> should be user controlled.
>>
>> There is no way MM or NM can know that one of my modems dont' have any
>> antennas connected, or that my operator only allows 3G so that LTE is
>> irrelevant, or that my internal modem tends to overheat, or ... I'm sure
>> you get the point.
>
>
> This is clearly the MM jobs to a least make those information available to
> D-Bus.
>

Still, that is not that clear to me.

ModemManager does already make all the modem-related information
available in DBus. In particular, MM already exposes the real device
names of the TTYs, cdc-wdms and WWAN netdevs being used for a given
modem.

But ModemManager does not track any modem-specific or SIM-specific
configuration; upper layers (e.g. NetworkManager) do this. Therefore,
if other applications (e.g. NetworkManager) need to track specific
configurations with specific devices, they could add udev flags
themselves and track them themselves. Or they could track symlinks to
the ttys (like /dev/modem) themselves, by using
g_udev_device_get_device_file_symlinks (). Updating the ModemManager
DBus API with information that others can already gather themselves
doesn't look like a good idea. Another thing would be if the others
were not able to do so and if ModemManager was the only one able to do
so (e.g. SIM ICCID, IMEI, IMSI...), but this is not the case.


>> Even simple things like internal vs external might be hidden from MM.
>> All modems are connected by USB to the same controllers.  We do have the
>> port/connect_type attribute nowadays, but that information comes from
>> the PC firmware (ACPI), and we can be pretty sure there is at least one
>> system getting it wrong.
>
>
> No, what you are talking about here is the udev job. And yes, an user could
> have a use case to select a modem based on the port/connect path. An other
> user could have a use case to match a specific modem product id. This is the
> advantage to use udev: it let the choice to the user. The standard why to
> manage devices on Linux today is to provides a list of udev rules that match
> the know devices on the market. This is why there is a /lib/udev/rules.d and
> /lib/udev/hwdb.d directories in your distribution. MM try to auto probing
> every serial ports, nobody do that anymore with udev. MM should only auto
> probe to find the good port on multiple port modem.
>
>> Every system and user is different. Policies have to be user defined.
>> Which implies configuration. So NM is the lowest level where you can
>> make this decision.
>>
>
> Certainly false: udev is the lowest level. There are reasons why MM already
> use udev variables.
>

Yes: we use udev variables when we cannot query the modem about the
purpose of the different ports, we use udev to flag specific port
types. This udev variables are needed for a correct operation of
ModemManager But this doesn't open a door to add udev rules to be
parsed and exposed by ModemManager for whatever other purposes that
users of ModemManager may have. NetworkManager is just one user of
ModemManager, not the only one.

If there is a need to manually manage udev variables to track specific
configurations for specific devices, then ok, do that, that's fine.
But asking ModemManager to read  those variables and expose them in
ModemManager's own DBus APIs is not the way to go, I think...

-- 
Aleksander
https://aleksander.es